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Abstract 


The  datacomputer  system  is  being  designed  as  a  large-scale 
data  storage  utility  to  be  accessed  from  remote  computers  on 
the  Arpanet  and,  potentially,  on  other  networks.  The 
development  is  phased,  with  each  successive  release  of  the 
system  offering  increased  capabilities  to  users.  During 
the  present  reporting  period,  the  second  major  release  of 
the  system  became  operational.  This  release,  while  still 
primitive  in  many  respects,  is  beginning  to  provide  experience 
with  actual  applications  and  user  programs. 
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1.  Overview 


1.1  Review  of  Basic  Concepts 

The  goal  of  the  project  continues  to  be  the  development  of 
a  shared,  large-scale  data  storage  utility,  to  serve  the 
needs  of  the  Arpanet  community. 

The  system  under  development  will  make  it  possible  to  store 
within  the  network  such  files  as  the  ETAC  Weather  Pile  or 
the  NMRO  Seismic  Data  File,  which  are  measured  in  hundreds 
of  billions  of  bits,  and  to  make  arbitrarily  selected  parts 
of  these  files  available  within  seconds  to  sites  requesting 
the  information.  The  system  is  also  intended  to  be  used  as 
a  centralized  facility  for  archiving  data,  for  sharing  data 
among  the  various  network  hosts,  and  for  providing  inexpensive 
on  line  storage  to  sites  which  need  to  supplement  their  local 
capability. 

Logically,  the  system  can  be  viewed  as  a  closed  box  which 
is  shared  by  multiple  external  processors,  and  which  is 
accessed  in  a  standard  notation,  "datalanguage"  (see  Fig.  1). 
The  processors  can  request  the  system  to  store  information, 
change  information  already  stored  in  the  system,  and  retrieve 
stored  information.  To  cause  the  datacomputer  to  take  action, 
the  external  processor  sends  a  ’’request"  expressed  in  data- 
language  to  the  datacomputer,  which  then  performs  the  desired 
data  operations. 

From  the  user's  point  of  view  the  datacomputer  is  a  remotely- 
located  utility,  accessed  by  telecommunications,  It  would  be 
impractical  to  use  such  a  utility  if,  whenever  the  user  wanted 
to  access  or  change  any  portion  of  his  file,  the  entire  file 
had  to  be  transmitted  to  him.  Accordingly,  data  management 
functions  (information  retrieval,  file  maintenance,  backup, 
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Figure  1.  Logical  View  of  Datacomputer 


access  security,  creation  of  direct  and  inverse  files,  main¬ 
tenance  of  file  directories,  etc.)  are  performed  by  the  data- 
computer  system  itself.  The  user  sends  a  ''request",  which 
causes  the  proper  functions  to  be  executed  at  the  datacomputer 
without  requiring  entire  files  to  be  shipped  back  and  forth. 

The  hardware  of  the  system  is  shown  in  overview  in  Fig.  2  and 
in  greater  detail  in  Fig.  3- 

The  program  for  the  system  processor  handles  the  interactions 
with  the  network  hosts  and  is  designed  to  control  up  to  three 
levels  of  storage:  primary  (core),  secondary  (disk),  and 
tertiary  mass  storage.  Currently,  the  CCA  facility  is  operating 
with  primary  and  secondary  storage  only,  with  the  addition  of 
tertiary  storage  planned  for  1975.  Installation  of  a  tertiary 
storage  module  will  leave  datalanguage  unchanged,  and  will 
therefore  be  imperceptible  to  users  of  the  system  (except 
insofar  as  it  affects  performance  and  the  total  storage  capacity 
available  for  data). 

In  addition  to  using  the  dedicated  equipment  at  CCA,  it  is 
planned  that  datacomputer  service  will  also  make  use  of 
hardware  resources  located  at  NASA/Ames,  using  CCA  software. 

The  two  sites  will  provide  mutual  backup  for  one  another, 
thereby  guarding  against  accidental  loss  of  data  and  providing 
for  satisfactory  uptime  of  the  overall  service. 


1.2  Status  of  Project 

During  this  reporting  period.  Version  0/10  of  the  datacomputer 
system  was  completed.  This  is  the  second  major  version  of  the 
system  to  offer  datacomputer  services  on  the  Arpanet.  Version 
0/10  has  replaced  Version  0/9-7',  which  was  an  "intermediate" 
release.  Version  0/10  handles  non-ASCII  and  variable-length 
data.  It  has  file-level  access  regulation.  (See  chapter  2  and 
Appendix  for  details.) 
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Figure  2.  Hardware  Overview  of  System 
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Figure  3- 


Hardware  Block  Diagram  -  CCA  Installation 
(Equipment  in  dashed  outline  is  planned  for  1975) 
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The  project  continues  on  an  increasing  scale  to  interact  with 
actual  and  potential  datacomputer  users.  New  user  programs 
have  given  us  more  operational  experience  with  the  system. 

Much  attention  is  being  paid  to  the  seismic  community,  the 
weather  community,  and  other  users  to  determine  their  data¬ 
computer  requirements  and  adjust  the  implementation  priorities 
accordingly . 

Currently  only  disk  storage  is  available  to  the  system.  A 
Calcomp  Dual  230  disk  was  installed  during  the  fourth  quarter 
of  1973.  A  second  Calcomp  Dual  230  lisk  will  be  added  later 
in  1974.  This  will  bring  the  total  CCA  storage  capacity  to 
about  4  billion  bits.  Plans  call  for  the  addition  of  large 
tertiary  storage  in  1975- 


2.  Software  Implementation 

During  this  reporting  period,  Version  0/10  replaced  Version 
0/9-7  as  the  system  offering  service  of  the  Arpanet.  The  new 
features  of  0/10  are  summarized  in  this  section.  (See 
Appendix,  "Datacomputer  Version  0/10  User  Manual"  for  details.) 
Specifications  and  implementation  of  Version  0/11  were  begun. 

2.1  Request  Handler 

Data  Description.  The  datalanguage  user  must  supply  descrip¬ 
tions  for  all  data,  whether  it  is  data  being  transmitted  to 
or  from  the  datacomputer  (port  description)  or  data  being 
stored  at  the  datacomputer  (file  description).  The  data  may 
be  tree-structured.  The  simple  data  types  handled  by  Version 
0/10  are  7-bit  ASCII,  8-bit  ASCII,  and  uninterpreted  bytes 
or  byte  strings  (with  a  user-specified  byte  size  less  than  or 
equal  to  36).  Variable-length  data  may  have  either  a  one- 
byte  preceding  count,  a  one-byte  delimiter,  or,  if  it  is  in 
a  port,  a  trailing  "punctuation'’  character  (i.e.,  end-of- 
record,  end-of-block,  or  end-of-file  marker-). 

The  previous  restriction  that  a  file  or  port  must  be  a  list 
has  been  lifted.  Also  lifted  is  the  size  restriction  that 
inner  containers  (i.e.,  containers  inside  of  files  or  ports) 
must  be  less  than  2560  characters. 

The  data  description  facilities  in  Version  0/11  will  be  the 
same  as  in  Version  0/10. 

Data  Operations  and  Access  Methods.  In  Version  0/10  the  user 
may  store  files,  retrieve  files,  replace  files,  and  append  to 
files.  The  user  may  also  retrieve  subsets  of  a  file  specified 
by  boolean  expressions  on  multiple  variables.  In  retrieving 
or  storing  data,  the  datacomputer  can  also  reformat  it. 
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Unlike  earlier  versions,  0/10  allows  members  of  Inner  level 
lists  to  be  used  In  boolean  expressions.  (This  is  sometimes 
called  a  keyword  feature;  it  allows  an  attribute  —  or 
container,  in  datalanguage  terms  —  that  occurs  several  times 
in  one  container  with  different  values  to  be  used  in  a 
retrieval  specification.)  Members  of  inner  level  lists  may 
also  be  Inverted.  However,  only  EQ  can  be  evaluated  using 
the  inversion;  evaluation  of  NE  still  requires  sequential 
search  of  the  data. 

Version  0/11  will  introduce  a  rudimentary  updating  capability. 
Replacement  of  uninverted  fixed-length  containers  will  be 
possible.  This  includes  fixed-length  containers  that  are 
inside  of  variable-length  containers. 

In  addition  to  specifying  a  set  of  containers  by  content,  in 
0/11  the  user  will  be  able  to  specify  a  set  of  containers  by 
position  in  a  list,  called  the  index  number  of  the  list 
member.  The  set  specif icatica  may  be  used  either  for  retrieval 
or  for  updating. 

In  order  to  allow  efficient  retrieval  of  variable-length 
containers,  the  auxiliary  structure,  called  a  Container 
Address  Table  (CAT),  will  be  implemented.  The  CAT  provides 
a  mapping  from  index  number  or  internal  record  number  to 
logical  address.  It  can  be  used  both  for  Indexed  and 
inverted  retrievals. 


Data  Privacy.  Version  0/10  has  directory-level  access 
regulation,  that  is,  regulation  at  the  file  level  and  higher. 
The  classes  of  users  are  defined  by  knowledge  of  passwords, 
by  host,  and/or  by  socket  number.  The  privileges  to  be 
granted  or  denied  are  read,  write,  append,  login,  and  control 
of  privileges. 


ft  -8- 


2.2  Services 


Version  0/10  supports  multiple  volumes.  This  allows  the 
datacomputer  to  use  both  of  the  CCA  3330-type  spindles  for 
storing  datacomputer  files.  These  disks  are  treated  as 
"special  disks",  not  as  part  of  the  normal  Tenex  page  space. 

A  utility  routine  that  dumps  datacomputer  files  to  magnetic 
tape  was  added.  It  can  run  as  a  background  job  without 
interfering  with  datacomputer  services. 


3.  Network  Services 


3.1  User  Programs 

The  datacomputer  Is  accessed  by  user  programs  which  run  on 
other  hosts  on  the  Arpanet  and  send  datalanguage  requests  to 
the  datacomputer.  In  order  to  gain  operational  experience 
with  the  datacomputer  and  the  problems  associated  with  using 
it,  and  in  order  to  facilitate  usage  of  the  datacomputer 
system,  CCA  has  written  a  number  of  user  programs. 

During  the  previous  reporting  period,  two  such  programs  were 
written:  SMART,  which  generates  datalanguage  for  users  at 
terminals,  and  PORPAC,  which  provides  an  interface  between 
Fortran  programs  and  the  datacomputer.  Based  on  our  experience 
with  these  two  programs,  a  set  of  standard  subroutines  (DCSUBR) 
needed  for  communication  with  the  datacomputer  were  specified 
and  implemented.  There  are  routines  to  set  up  network 
connections,  send  datalanguage,  send  data,  read  data,  and  the 
like.  Written  in  Macro-10,  DCSUBR  serves  as  a  model  for 
similar  programs  to  be  written  ‘'or  other  machines. 

One  of  the  user  programs  to  incorporate  DCSUBR  is  RDC  (Run 
Datacomputer).  RDC  provides  convenient  terminal  access  to 
the  dacacomputer  from  a  Tenex  host.  Datalanguage  is  trans¬ 
mitted  from  either  a  teletype  or  from  a  local  Tenex  file, 
and  datacomputer  responses  are  displayed. 

At  the  user's  request,  RDC  will  set  up  a  secondary  network 
connection  as  a  data  path  to  or  from  the  datacomputer.  This 
allows  for  transfer  of  non-ASCII  data  (not  accepted  over  the 
datalanguage  port)  and  it  results  in  more  efficient  data 
transfers  over  the  network.  Unlike  other  user  programs,  RDC 
does  not  generate  datklanguage ;  rather  it  gives  a  person  a 
way  to  submit  his  own  datalanguage.  (The  only  exceptions 
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are  the  datalanguage  CONNECT  and  DISCONNECT  statements.) 

EDC  has  been  useful  for  debugging  and  for  setting  up  new  data 
bases . 

A  second  program  to  utilize  DCSUBR  is  DFILE.  DFILE,  which 
runs  on  any  Tenex  host,  allows  local  user.-  to  archive  their 
files  on  the  datacomputer- .  The  user,  from  his  terminal,  can 
associate  attribute-value  pairs  with  his  file,  and,  later, 
retrieve  the  proper  files  based  on  boolean  combinations  of 
these  pairs.  DFILE  may  be  used  advantageously  for  files 
whose  usage  is  not  limited  to  a  single  host  or  for  files 
which  are  public  and  meant  to  be  distributed.  The  attribute- 
value  pairs  give  the  DFILE  user  a  way  of  browsing  through  the 
DFILE  database  to  find  out  what  files  are  available. 


3.2  User  Statistics 

The  following  chart  indicates  the  number  of  times  each 
network  site  has  connected  to  the  datacomputer  in  the  present 
reporting  period.  During  the  period  March  through  May,  both 
Versions  0/9-7  and  0/10  were  available  over  the  Arpanet.  The 
figures  for  this  period  indicate  the  changeover  from  one 
version  to  the  next. 
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Chapter  Is  Introduction  to  the  Datacomputer 


Introduction 

The  datacomputer  Is  a  shared  large-scale  data  utility 
system  designed  to  serve  the  computers  on  the  ARPA  network. 
It  may  be  thought  of  as  a  "black  box"  that  performs  data 
storage  and  retrieval  functions  In  response  to  commands 
phrased  In  a  standard  notation,  called  datal anguage . 

This  document  describes  the  currentl y-runn I ng  version 
of  the  datacomputer  software,  and  Includes  Information  about 
how  a  user  program  can  access  the  system,  transmit 
datalanguage,  process  the  datacomputer 's  responses,  and 
transmit  and  receive  data  over  the  network. 

The  datacomputer  In  Its  full  implementation  will 
provide  an  on-line  storage  capacity  of  one  trillion  bits  and 
an  extensive  set  of  services  to  user  programs.  (1)  The 
present  version  Is  a  preliminary  version,  providing  a 
limited  amount  of  storage  and  a  restricted  set  of  user 
functions.  Subsequent  versions  will  progressively  enlarge 
the  range  of  services  and  the  amount  of  storage  available 
for  users. 


(1)  See  Datacomputer  Project  Working  Paper  No.  8,  Further 
Datalanguage  Design  Consents/  December  1973. 


Page  4 


Chapter  2:  Containers 
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The  container  is  a  basic  concept  in  datalanguage .  A 
container  is  an  imaginary  box  which,  like  a  FORTRAN 
variable,  may  contain  data;  a  container  may  also  enclose 
other  containers.  For  example,  some  information  about 
people  could  be  represented  as: 


Figure  2-1.  A  container  structure 


Here  PEOPLE,  PERSON,  NAME,  and  ADDRESS  are  containers 
enclosing  other  containers;  FIRST,  LAST,  STREET,  CITY, 
STATE,  and  SOCSECNO  are  containers  that  enclose  only  data. 

The  description  of  a  container  has  several  parts.  It 
includes  the  container's  ident,  type,  and  size,  and  perhaps 
some  additional  attributes.  The  container's  ident.  or 
simple  name,  is  a  string  of  100  or  fewer  letters,  digits  or 
the  special  character  fc,  by  which  datalanguage  requests 
refer  to  the  container.  The  first  character  of  an  Ident 
must  be  a  letter  or  the  character  X.  Certain  reserved  words 
may  not  be  used  as  container  idents;  these  are  listed  in 
Appendix  B  of  this  document. 


Some  sample  idents  are: 
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AVERYLONG I DENTABCDEFGH i JKLMNOPQRSTUVWXYZ 
PEOPLE 

WEATHEROSTATiONS 

tCCA 


Containers  are  of  four  types-  depending  on  their 
contents. 

A  container  that  is  a  LIST  contains  some  number  of 
other  containers.  The  LIST-members  may  be  containers  of  any 
data  type/  but  they  must  all  have  the  same  description. 
PEOPLE  (above)  is  an  example  of  a  LIST. 

A  container  that  is  a  STRUCT,  or  STRUCTURE,  contains 
some  number  of  other  containers/  which  need  not  have 
identical  descriptions^  1)  The  descriptions  of  all  the 
containers  that  are  enclosed  by  the  STRUCT  form  part  of  the 
description  of  the  STRUCT  itself;  and  on  every  occurrence  of 
the  STRUCT  every  one  of  its  sub-containers  must  appear  in 
the  same  order.  ADDRESS  is  an  example  of  a  STRUCT. 

A  container  of  type  BYTE  contains  one  byte  of  data.  A 
container  that  is  a  STR  or  STRI NG  contains  a  string  of 
bytes. (2)  FIRST  is  an  examp’e  of  a  STR.  The  user  can 
specify  the  byte  size  of  BYTEs  and  STRs  and  can  indicate  an 
interpretation  of  7-  or  8-blt  ASCII  or  uninterpreted  (See 
below) . 

A  LIST  or  STR  has  a  size  associated  with  it.  The  size 
may  be  fixed  or  variable.  The  size  of  a  STR  is  the  number 
of  characters  in  it/  while  the  size  of  a  LIST  is  the  number 
of  elements  in  the  LIST. 


Outer-most  Containers 

A  container  that  is  not  contained  by  any  other 
container  Is  called  an  outermost  container:  outermost 
containers  are  different  in  several  respects  from  other 
contai ners. 

An  outermost  container  in  datalanguage  has  a  function, 
which  is  either  FILE/  PORT/  or  TEMPORARY  PORT  (which  may  be 
abbreviated  TEMP  PORT).  A  FILE  contains  data  kept  in  the 
datacomputer .  When  a  FILE  is  created  (see  below)/ 
datacomputer  space  is  allocated  for  it.  A  PORT  describes 
data  that  is  transmitted  to  or  from  the  datacomputer.  A 
TEMP  PORT  is  a  PORT  whose  description  is  not  permanently 


(1)  STRUCT  and  STRUCTURE  are  synonyms  in  datalanguage. 
Hereafter/  STRUCT  will  normally  be  used. 

(2)  STR  and  STRING  are  synonyms  in  datalanguage.  Hereafter, 
STR  will  normally  be  used. 
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stored,  unlike  the  descriptions  of  other  containers.  TEMP 
PORTs  vanish  at  the  end  of  the  session  In  which  they  were 
created. 


Ih£  QLrectorv 

The  I  dent  of  an  outermost  container,  whether  It  Is  a 
FILE  or  a  PORT,  Is  unlike  other  Idents,  In  that  It  Is 
entered  in  the  datacomputer ' s  di rectory.  The  directory  Is 
conceptually  a  tree;  the  entries  in  It  are  called  nodes .  A 
node  may  have  one  or  more  subordinate  nodes,  unless  It 
represents  a  container,  in  which  case  it  cannot.  A  portion 
of  a  hypothetical  directory  is  diagrammed  below;  It  may  be 
read  as  indicating  that  the  nodes  F  and  G  are  subordinate  to 
DATA,  which  in  turn  Is  subordinate  to  CCA.  Only  the 
bottom-most  nodes  In  this  tree,  F  and  G,  may  represent 
containers,  and  they  represent  outermost  containers. 


Figure  2-2.  A  portion  of  the  directory. 


Only  a  bottom-most  node  of  the  directory  may  be  a  container 
ident;  only  an  outermost  container  has  its  ident  entered  In 
the  directory. 

Normally,  the  first  thing  a  user  does  after  attaching 
to  the  datacomputer  Is  log  in  to  a  directory  node.  For  most 
purposes,  he  only  sees  his  login  node  and  the  part  of  the 
directory  that  Is  subordinate  to  his  login  node.  (The  LOGIN 
request  Is  discussed  In  detail  in  Chapter  4.) 
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Pathnames 

Pathnames  are  used  to  reference  nodes  in  the  directory 
tree  by  describing  a  path  through  it.  They  have  the  general 
hierarchical  form 

N0DE1.N0DE2. . . NODEn 

where  N0DE2  is  a  node  directly  subordinate  to  N0DE1. 

There  are  several  varieties  of  pathnames.  The  two 
classes  of  directory  objects  referenced  by  pathnames  are 
closed  nodes  (including  all  nodes  that  are  not  outermost 
containers  and  all  outermost  containers  that  are  not  OPEN) 
and  OPEN  outermost  containers.  There  are  three  areas  in 
which  names  can  be  found:  the  TOP#  LOGIN#  and  OPEN  contexts. 
Thus  there  are  six  possible  pathname  types#  only  five  of 
which  are  reasonable.  (A  closed  node  In  the  OPEN  context 
isn't.) 

Closed  nodes  can  be  referenced  either  by  a  complete 
pathname  (started  with  the  reserve*4  word  STOP)#  which  causes 
the  name  search  to  be  anchored  at  the  top  of  the  directory 
tree#  or  a  ^OGIN  pathname#  which  anchors  the  search  at  the 
current  LOGIN  node.  Either  pathname  may  contain  passwords. 
(Passwords  are  discussed  in  Chapter  4.) 

OPEN  nodes  may  be  referenced  by  a  simple  complete 
pathname  or  a  simple  LOGIN  pathname#  neither  one  of  which 
can  contain  passwords#  or  by  an  OPEN  node  simple  name.  An 
OPEN  node  simple  name  Is  the  name  of  the  outermost 
container. 


Ccfiallrig  Nodes 

A  node  In  the  directory  is  created  with  a  CREATE 
request.  Such  a  request  has  the  form 

CREATE  <  path, name)  ; 

Only  one  node  may  be  created  by  a  single  CREATE  request#  and 
a  higher-level  node  must  always  be  created  before  one 
subordinate  to  it.  The  reserved  words  listed  in  Appendix  B 
may  not  be  used  as  directory  node  names. 

As  an  example#  let  us  create  the  outermost  container  F# 
a  LIST  of  4-character  strings;  the  container's  Ident  will  be 
entered  In  the  directory  as  indicated  in  Figure  2-2,  We 
assume  that  nothing  Is  presently  in  the  directory,  so  we 
must  start  by  creating  the  topmost  node. 
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CREATE  CCA; 

CREATE  CCA. DATA; 

CREATE  CCA. DATA, F  FILE  LIST 
F00  STR  (4)  ; 

Now  that  CCA  and  CCA. DATA  have  been  created/  we  could 
create  CCA. DATA. G  with  only  one  CREATE  request;  l.e. 

CREATE  CCA. DATA. G  f'ORT  LIST  etc. 


Cr-fi,fltLnfl  Containers 

Outermost  containers  are  created  by  a  more  complicated 
form  of  the  CREATE  request.  The  CREATE  statement  must  tell 
the  datacomputer  all  about  the  container/  for  example/  Its 
ident/  function/  size#  and  data  type  are  Included.  An 
outermost  container  and  all  Its  subcontainers  must  be 
created  at  once/  with  one  CREATE  request. 

The  CREATE  request  causes  the  description  to  be  stored. 
It  also  causes  space  to  be  allocated  If  the  container  Is  a 
FI  LE. 


The  full  BNF  In  Appendix  A  Indicates  succinctly  the 
precise  syntax  of  the  CREATE  statement.  It  Is  worth  looking 
at  a  few  examples  before  looking  at  all  the  details  of 
descriptions.  A  LIST  of  STRIngs: 

CREATE  ALPHA  FILE  LIST  SUBCONTAI NEDSTRI MG  STR  (44)  ; 

Here  the  size  of  the  outermost  LIST  Is  omitted/  so  the 
datacomputer  will  calculate  a  default  size. 

A  LIST  of  STRUCTS/  each  of  which  contains  three 
strings: 

CREATE  BALLTEAM  FILE  LIST  (25) 

PLAYER  STRUCT 
NAME  STR( 20) 

POSITION  STR( 2) 

UNI FORM%NUMBER  STR(2) 

END; 

The  datacomputer  will  allocate  enough  space  for  the  file 
BALLTEAM  to  hold  25  copies  of  the  STRUCT  named  PLAYER.  Note 
that  END  Is  required  to  terminate  the  description  of  the 
STRUCT. 

The  example  diagrammed  on  page  4: 

CREATE  PEOPLE  FILE  LIST 
PERSON  STRUCT 
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NAME  STRUCT 
FIRST  STR( 15) 
LAST  STR(  15) 
END 

ADDRESS  STRUCT 
STREET  STR( 15) 
CITY  STR{ 15 ) 
STATE  STR  (15) 
END 

SOCSEC'NO  STR(IO) 
END; 


The  elementary  data  types  are  BYTE  and  STR.  Containers 
of  these  types  contain  data#  not  other  containers. 

STRings  and  LISTs  must  have  a  size.  For  STRings#  the 
size  is  the  number  of  bytes  in  the  STRinc.  For  LISTs  the 
size  is  the  number  of  LIST  members  (e.c.  the  number  of 
PERSONS  in  PEOPLE  above.)  The  three  forms  for  indicating  the 
size  are: 

(n)  --  a  fixed  size  of  n 

(m#n)  --  a  minimum  size  of  m  and  a  maximum  of  n 

(#n)  —  a  minimum  dimension  of  0  and  a  maximum  of  n 

where  m  and  n  are  positive  Integers. 

For  an  outermost  LIST  or  STRing#  no  size  need  be 
specified.  The  default  minimum  is  0#  and  the  default 
maximum  is  based  on  what  will  fit  in  the  default  space 
al location. 

The  datacomputer  needs  a  way  to  find  the  end  of  the 
data  in  variable-sized  LISTs  and  STRings.  The  three  options 
are  a  preceding  count#  a  trailing  character#  and  punctuation 
(i.e.  a  device-dependent  marker).  A  one-byte  preceding 
count  is  indicated  with  the  keyword  parameter 

#C*1 

Version  0/10  cannot  handle  counts  larger  than  one  byte. 
Thus#  if  there  is  a  count#  then  the  maximum  dimension  must 
be  small  enough  to  fit  into  a  one-byte  count.  (Byte  size  is 
discussed  further  below.)  The  value  of  the  count  does  not 
include  the  count  byte  itself. 

The  syntax  to  Indicate  that  there  Is  a  one-byte 
delimiter  is 

#  D«n 


or 
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/D*,a' 

where  n  is  a  decimal  number  and  a  is  any  ASCII  number, 
letter  or  special  character. 

The  datacomputer  considers  punctuation  to  be  different 
from  delimiters.  Punctuation  over  the  network  Is  a  special 
character  (specifically  EOR,  EOB,  or  EOF)  inserted  in  the 
data  but  not  considered  part  of  the  data.  This  Is  indicated 
by 

,P»E0R 

, P=E0B 

and 

, P=E0F 

A  fixed-size  container  (including  a  STRUCT)  may  have  a 
P,  D  or  C  parameter,  but  no  container  (fixed  or  variable) 
may  have  more  than  one  of  these. 

A  datacomputer  FILE  can  be  punctuated,  hut  none  of  its 
sucontainers  can  be.  The  FILE  punctuation  defaults  to  EOF. 
Variable-length  subcontainers  must  have  either  a  C  (count) 
or  D  (delimited)  parameter. 

if  a  variable-sized  PORT  does  not  have  a  P,  D,  or  C 
parameter,  then  it  defaults  to  P*E0F.  Variable-sized 
subcontainers  of  a  PORT  default  to  P=E0R. 

Punctuation  Is  h i erarch I  cal .  A  container  that  is 
punctuated  with  EOR  cannot  contain  one  that  Is  punctuated 
with  EOB  or  EOF.  A  container  that  !s  punctuated  with  EOB 
cannot  contain  one  with  EOF.  If  higher  punctuation  Is  found 
in  a  data  stream  where  the  datacomputer  is  looking  for  lower 
punctuation  (e.g.,  an  EOB  where  an  EOR  is  expected),  the 
higher  punctuation  implies  the  lower. 


(1)  Note  that  the  default  punctuation  for  PORTs  Is  different 
from  what  It  was  in  Version  0/9.  Consider  the  description 

CREATE  P  PORT  LIST 
R  STRUCT 
A  STR  (1) 

B  STR  (1) 

END; 

FOR  VERSION  0/9  EVERY  R  MUST  END  WITH  AN  EOR.  In  Version 
0/10,  since  R  Is  fixed-size,  no  EOR's  are  expected,  and  an 
error  message  Is  output  if  an  EOR  or  EOB  Is  found.  If  R's 
end  wi th  EOR,  then 

,P«E0R 

should  be  added  to  the  description  of  R. 
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The  I nterpretatlon  of  a  STR  Is  one  of  ASCII  (l.e. 
7-blt  ASCII),  ASCI  18,  or  BYTE,  as  In  the  following  three 
examples: 

A  STR  ASCI  I  (5) 

P  STR  ASCI  I  8  (1,10),  C-l 
WALDO  STR  BYTE  (73) 

The  default  byte  size  for  BYTE  Is  36  bits.  BYTE  Is  optional 
If  the  byte  size  Is  given  explicitly  with  the  keyword 
paramter 

,BBn 

where  n  Is  a  positive  Integer  less  than  or  equal  to  36.  The 
,B*n  option  may  not  be  used  for  ASCII  STRlngs.  If  no  byte 
size  or  Interpretation  Is  given,  then  the  STR  Is  7-blt 
ASCI  I . 

At  times  the  datacomputer  needs  to  fill  In  a  value  or  a 
part  of  a  value.  The  user  can  specify  a  fill  character 
thus: 

, F* 'a ' 
or 

/  F=n 

where  a  I s  an  ASCII  character  and  n  Is  a  decimal  number. 
The  default  fill  character  Is  blank  for  ASCII  data  and  zero 
for  non-ASCII  data. 

Note  that  a  byte  size  and  a  fill  character  can  apply  to 
a  STRUCT  or  a  LIST  as  well  as  a  STR  or  a  BYTE.  Consider  the 
fol (owl ng: 

CREATE  F  FILE  LIST 

R  STRUCT,  B-36 
A  STR  (5) 

END; 

The  byte  size  of  A  Is  7.  A  takes  up  35  bits.  There  Is  one 
"unused"  bit  after  A  before  the  next  R.  Thus,  R  must  be 
filled.  Even  though  the  data  (l.e.  A)  Is  ASCII,  R  Is 
non-ASCII  because  It  does  not  have  a  7-blt  byte  size. 
Hence,  the  default  filler  of  0  Is  used  for  the  bit. 

The  rules  for  punctuation,  byte  size  and  fillers  are 
simple  but  not  at  all  intuitive.  In  general,  specifying 
punctuation  rather  than  relying  on  defaults  helps  avoid 
errors.  Also 


LIST  <pathname>  %DESC; 
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will  output  a  complete  description#  including  all  default 
lengths#  dimensions#  punctuation#  byte  sizes  and  fillers. 
(The  LIST  command  Is  discussed  more  fully  below.)  It  Is 
often  instructive  to  look  closely  at  the  iDESC  to  see  where 
It  is  different  from  what  the  user  expects. 

BYTEs  and  STRIngs  that  will  frequently  be  used  for 
retrieval  may  be  inverted.  For  members  of  outer  USTs#  the 
option 


#  l-D 

Is  used,  for  members  of  inner  LISTs#  the  option 

,1*1 

Is  used.  Inversions  and  the  difference  between  outer  list 
members  and  inner  list  members  is  discussed  more  fully  In 
the  section  on  WITH. 
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OPEN 

Before  data  can  be  Input  to  or  read  from  a  FILE  or 
PORT,  the  container  must  be  ooen,  and  a  mode  must  be 
specified  for  It.  The  mode  of  a  FILE  or  PORT,  which  Is  set 
when  the  container  Is  opened,  determines  the  legality  of 
various  operations  on  that  container. 

Mode  Is  one  of  READ,  WRITE,  or  APPEND.  Data  can  only 
be  transmitted  out  of  a  FILE  or  PORT  that  Is  open  In  READ 
mode,  but  either  out  of  or  Into  a  FILE  or  PORT  th«~t  Is  open 
In  WRITE  or  APPEND  modes.  The  difference  between  WRITE  and 
APPEND  lies  In  their  treatment  of  any  data  that  Is  already 
In  the  container  when  It  Is  opened.  When  an  assignment  Is 
made  to  a  container  that  was  opened  In  WRITE  mode,  any  data 
It  contained  previously  Is  thrown  away,  but  a  container 
opened  In  APPEND  mode  has  newly-arrl vlng  data  written  after 
the  end  of  any  al ready-present  data,  which  Is  thus 
preserved. 

A  variation  of  WRITE  and  APPEND  Is  WRITE  DEFER  and 
APPEND  DEFER.  When  DEFER  is  Indicated  as  part  of  the  mode, 
a  more  efficient  technique  of  updating  the  inversion  is 
used. 

When  a  FILE  or  PORT  is  created,  it  is  opened  in  WRITE 
mode.  A  FILE/PORT  that  already  exists  may  be  opened  with  an 
OPEN  request: 

OPEN  <pathname>  <mode>  ; 

which  specifies  the  name  of  the  container  that  is  to  be 
opened  and  the  mode  of  opening.  The  name  can  he  either  a 
complete  pathname  (started  with  the  reserved  word  $TOP)  or 
it  can  be  a  login  pathname,  started  with  a  node  Immediately 
subordinate  to  the  current  login  node.  The  mode  must  he  one 
for  which  the  user  has  privileges  (see  Chapter  4).  The  mode 
argument  may  be  left  out  of  an  OPEN  statement.  In  which  case 
the  container  is  opened  in  READ  mode  if  it  is  a  FILE  and 
WRITE  mode  If  It  is  a  PORT.  Two  outermost  containers  with 
the  same  ident  may  not  be  open  at  the  same  time. 

For  example,  to  read  data  that  was  previously  stored  in 
CCA. DATA. F,  a  file,  either 


OPEN  CCA. DATA. F; 
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or.  If  the  current  login  node  Is  CCA, 

OPEN  DATA, F; 

WILL  OPEN  F  PREPARATORY  TO  DATA  TRANSFER  REQUESTS. 
MODE 


The  mode  of  a  container  that  Is  already  open  may  be 
changed  with  the  MODE  statement: 

MODE  <paragraph>  <mode>  i 

The  pathname  car.  be  a  simple  complete  pathname  (l.e.  a 
complete  pathname  with  no  passwords),  a  simple  login 
pathname,  or  a  node  name. 


The  complement  of  the  OPEN  request  Is  the  CLOSE 
request.  When  you  have  finished  using  an  open  container, 
close  it  wl th 

CLOSE  <pathname>  ; 

where  pathname  must  be  the  simple  pathname  of  an  open 
container.  Closing  a  FILE/PORT  with  a  function  of  TEMPORARY 
PORT  has  the  effect  of  deleting  its  description  from  the 
datacomputer . 


delete 

The  ability  to  delete  directory  nodes  Is  useful  in 
maintaining  a  data  base  at  the  datacomputer.  The  DELETE 
request  allows  one  to  delete  one  or  several  outermost 
containers  and  all  the  data  they  contain. 

DELETE  <pathname>  ; 

causes  the  node  named  by  <pathname>  to  be  deleted  from  the 
directory.  The  pathname  must  be  the  login  pathname.  Thus, 
only  nodes  subordinate  to  the  login  node  can  be  deleted. 
The  node  cannot  have  any  subordinates. 

DELETE  <PATHNAME> . **  ; 

deletes  the  node  and  all  subordinate  nodes.  If  any  of  the 
deleted  nodes  are  outermost  containers,  the  container 
descriptions  and  any  associated  data  are  deleted  as  well. 
The  DELETE  request  need  not  be  used  on  TEMPORARY  PORTs,  as 
they  are  automatically  deleted  either  when  they  are  closed. 
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or  at  session  end. 

If  the  data  stored  in  FILE  is  to  be  deleted,  but  the 
container  description  Itself  retained  in  storage,  the  DELETE 
request  cannot  be  used,  instead,  CREATE  a  port  B  with  a 
description  matching  the  container  A  that  is  to  be  emptied, 
and  execute  the  assignment  A  *  B  with  no  data  in  B.  the 
effect  of  this  assignment  is  to  delete  all  the  data  from  A. 


LIST 

The  LIST  request  Is  the  means  by  which  the  user 
Interrogates  the  datacomputer  about  his  environment.  The 
request  has  two  arguments:  the  node  or  nodes  which  are  the 
object  of  the  Inquiry,  end  the  type  of  information  desired. 

The  first  argument  consists  of  a  set  of  nodes  In  the 
directory.  Possible  node  sets  are:  1)  a  single  node,  2)  all 
nodes  directly  subordinate  to  a  given  node,  3)  a  node  and 
all  its  subordinates,  and  4.'  all  open  files  and  ports.  A 
single  node  is  specified  with  a  full  pathname,  which  can 
include  passwords  and  can  be  anchored  at  the  top  node 
(tTOP).  The  set  of  a  node's  direct  subordinates  Is 
indicated  with  either  a  "*"  (the  login  pathame  Is  Implicit) 
or  a  full  pathname  followed  by  a  "*".  Either  "**"  or  a  full 
pathname  followed  by  a  "**"  designates  a  node  and  all  Its 
subordinates.  The  set  of  all  open  nodes  Is  referenced  by 
{OPEN.  $T0P  alone  defaults  to  STOP.**. 

There  are  five  kinds  of  available  information.  These 
are:  1)  node  names  and  related  data  (node  type,  privileges, 
and  possibly  mode  and  connected  argument),  2)  parsed  data 
descriptions  (of  FILES  and  PORTs),  3)  original  source  text 
of  data  descriptions,  4)  allocated  space  (for  FILEs),  and  5) 
privilege  blocks  associated  with  nodes.  These  Information 
options  are  specified  by  SNAME,  SDESC  or  %DESCRI PTI ON, 
SSOURCE,  SALLOC  or  ^ALLOCATION,  and  SPRIV  or  ^PRIVILEGE, 
respectively.  The  default  option  is  %NAME. 

Not  all  of  the  kinds  of  information  are  available  for 
all  of  the  possible  node  sets.  The  options  that  are 
aval lable  are: 


Node  Set 

<pathname> 

<pathname> 

<pathname> 

<pathname> 

<pathname> 

<pathname>.* 

<pathname> .** 


Option 

*DESC 

INAME 

^SOURCE 

^ALLOCATION 

%  PR I  VI  LEGE 

*NAME 

*  NAME 
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<pathname>.** 

$0PEN 

%0PEN 

tOPEN 

%0PEN 


^SOURCE 

%NAME 

^DESCRIPTION 

^SOURCE 

^ALLOCATION 
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Introductory  ConCfttt^S 

The  0/10  version  of  the  datacomputer  provides  file-level 
security  (restricted  access  to  nodes  and  attendant  data)  by 
means  of  a  system  of  or i vl lege  blocks,  described  In  the 
following  sections.  One  or  more  (or  no)  blocks  may  be 
associated  with  a  particular  node.  Each  privilege  block 
defines  a  class  of  users  who  may  be  given  access  to  the  node 
and  the  set  of  or i vi 1 eges  to  be  granted  to  such  users. 
Whenever  a  user  attempts  to  access  a  node  or  file,  the 
datacomputer  will  scan  that  node  or  file's  privilege 
block(s).  If  any,  to  ensure  that  the  user  Is  'legal'  and  to 
determine  what  privileges  will  be  allowed. 


Chapter  flrganizatlon 

This  chapter  Is  divided  into  three  principal  parts.  The 
first  sections  describe  what  privilege  blocks  are  and  how 
they  provide  file  security  functions  for  datacomputer  users, 
and  Introduce  the  reader  to  the  security  features  of 
datalanguage.  The  second  part  completely  specifies  the 
datalanguage  needed  for  creating,  deleting  and  manipulating 
privilege  blocks,  and  completes  the  description  of  their 
components  begun  In  the  first  part.  The  third  section 
offers  several  examples  of  how  to  add,  delete  and  look  at 
pr I vl lege  blocks. 


fialnlnr.  Access  la  Nodes ;  log  i  n 

Every  node  in  the  directory  has  certain  privileges 
associated  with  it.  For  example,  the  ability  to  create 
inferior  nodes,  or  to  read  or  write  file  data,  are 
privileges  which  may  be  granted  or  denied  to  a  particular 
node.  When  a  user  initially  connects  to  the  datacomputer  he 
Is  automatically  connected  to  the  top  node  of  the  directory 
tree  ($T0P),  ar.d  he  (i.e.,  the  %T0P  node)  Is  granted  minimal 
privileges.  To  acquire  more,  he  must  log  In  to  some  node, 
which  is  called,  curiously  enough,  the  login  node. 

Logging  Into  this  node  establishes  the  user's  Identity  for 
subsequent  pathname  references  (1).  It  should  he  kept  In 


(1)  In  addition  to  establishing  a  user  identity  for 
pr*vilege  purposes,  logging  In  performs  various  accounting 
and  pathname  context  functions. 
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mind  that  a  user  is  identified  to  the  datacomputer 
his  login  node.  Thus,  throughout  this  chapter, 
'user-id'  or  'user  name'  are  to  be  understood 
nothing  more  than  the  full  pathname,  including  the 
privilege  block  (if  any)  at  each  level  (2),  of  the 
which  the  user  has  logged-in. 


only  by 
the  terms 
to  mean 
specified 
node  to 


Whenever  a  logged- in  user  references  a  node,  the  login 
pathname  is  compared  against  the  user-id  field  of  every 
block  in  the  node's  privilege  block  list.  If  a  block  is 
found  whose  user  class  description  includes  the  pathname  of 
the  login  node,  the  privilege-set  described  by  the  block 
will  be  added  to  (or  taken  away  from)  the  privilege  set 
already  given  to  the  login  node. 


Privileges 

Privilege  set  specifications  come  In  two  flavors:  privileges 
to  be  granted  (added)  to  the  node  and  privileges  to  be 
denied  (taken  away).  If  a  privilege  Is  not  specified  (as 
either  grant  or  deny),  then  that  privilege  (or  denial  of  It) 
is  passed,  unchanged,  from  the  superior  node  to  Its 
subordinate.  At  each  node  level,  the  deny  hits  specified  In 
the  given  privilege  block  are  NOT-AND'ed  with  the  privileges 
of  the  superior  node.  Then  the  grant  privileges  are  OR'ed 
with  the  result,  to  yield  the  privilege  set  for  that  node. 

It  is  Important  to  understand  that  ori  vl  leges  may  ]*£  added 
.and  taken  SHLmjl  al  every  level  &£  IlL£  pathname..  For  example, 
suppose  the  login  node  has  the  privilege  set  <CLWA>  (3),  and 
a  subnode's  privilege  block  specifies:  grant  read  privilege 
(G*P«),  and  deny  write  privilege  (D*W).  The  result  at  the 
subnode  would  be  the  final  privilege  set  of  <CRA>  (4). 


(2)  Pathnames  may  be  email f i ed  or  unaual i f I ed.  A  qualified 
pathname  is  one  containing  password  strings  for  the  purpose 
of  gaining  particular  privileges  upon  opening  the  node, 
e  «g  • , 


NODEK  '  PASSWORD  1'  )  .  NOD E 2.  NODE 3 ( '  PW3' ) 

is  a  pathname  qualified  at  the  first  and  third  levels  by  the 
passwords  'PASSW0RD1'  and  'PW3',  respectively.  The  pathname 
N00E1.N0DE2. NODE 3,  on  the  other  hand,  is  unqualified.  Prior 
to  Version  0/10,  all  pathnames  were  unqualified. 


(3)  This  is  a  shorthand  way  of  saying  'this  node  has  been 
granted  control  <C>,  login  <L>,  wr i te-to-f i 1e  <W>  and 
append-to-f i le  <A>  privileges.  Specific  privileges  are 
described  in  detail  below. 
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Note  that  a  node  can  never  look  at#  modify,  or  affect  a 
superior  node  in  any  way  not  possible  at  the  level  of  the 
superior.  That  is,  if  a  user  cannot  look  at  the  privilege 
blocks  for  a  node,  he  cannot  acquire  that  privilege  for  that 
node  from  an  inferior  one.  However,  an  inferior  node  may 
well  have  privileges  relative  to  its  suhnodes  that  its 
superior  does  not  have  relative  to  Its  subnodes.  For 
example,  scanning  along  the  pathname  A.B.C.D.E.. . .,  A.B.C 
may  have  only  read  privileges,  but  does  not  have  write 
privilege.  Now,  the  node  A.B.C.D  may  be  granted  write 
privilege  at  level  D  (thus  awarding  A.B.C.Ii  read/write 
privileges),  this  does  not  affect  A.B.C.  It  still  has  only 
read  pr i vi lege. 


Prlyl Isis  Black 

Privilege  blocks  are  data  structures  which  define  access  to 

nodes.  Each  privilege  block  is  associated  with  one 

particular  ncde.  Any  node  in  the  directory.  Including  ports 
and  file,  may  have  privilege  blocks  defined  for  them.  A 
node  may  have  any  number  (including  zero)  of  privilege 
blocks.  When  an  attempt  is  made  to  access  a  node  which  has 

privilege  block(s),  those  blocks  are  scanned  for  a  user-id 

corresponding  to  the  current  login  pathname  and  for  a 
password  string  matching  that  supplied  by  the  user  In  the 
request  referencing  the  node  (e.g.,  LOGIN,  OPEN,  DELETE, 
etc.).  If  a  match  Is  found,  the  matching  block's  privilege 
set  bits  are  examined  and  the  appropriate  privileges  are 
granted/denied  the  node.  The  matching  algorithm  Is 
described  below  in  more  detail. 

Each  privilege  block  can  contain: 
user  name 
host  name 
socket  number 
password  character  string 
grant  pr i vi leges 
deny  pr I vi leges 

Each  of  the  above  fields  fells  into  one  of  two  categories: 
1)  a  description  of  the  group  of  users  which  may  access  the 
associated  node;  and  2)  the  privileges  to  be  granted  to 
these  users. 

The  privilege  block  is  completely  specified  at  the  time  it 
is  created.  When  a  node  is  referenced,  only  the  password 
string,  if  any,  is  required;  the  user-id  (including  host 
name  and  socket  number),  has  been  retained  by  the  login 
process. 

(4)  The  login  privilege  is  not  propagated  to  subnodes.  it 
applies  only  to  the  node  for  which  it  Is  explicitly  granted. 
See  below. 


i 

i . 
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Privilege  blocks  are  created  by  the  tiatalanguage  command 
CREATEP.  They  are  deleted  by  the  command  DELETEP.  Existing 
privilege  blocks  may  be  displayed  via  the  LIST  nodename 
tPRIV(ILEGE)  command.  The  full  syntax  of  these  commands  is 
described  below. 


Identification  ELelds  lUser-ID) 

The  user  identification  fields  include  some  or  all  of  the 
following:  a  valid  login  pathname  or  a  class  of  login 
pathnames/  the  number  of  a  host  computer/  the  datacomputer 
socket  number/  and  a  password  character  string.  These 
fields  are  discussed  in  more  detail  In  the  following 
sections. 


Ufi&t 

The  host  name  is  an  optional  field.  If  specified/  it  must 
be  a  decimal  number  from  1  to  255  designating  the  number  of 
the  host  computer.  The  host  name  cannot  be  a  number  greater 
than  255/  or  less  than  1.  It  cannot  be  a  character  string/ 
except  for  the  special  cases  LOCAL  and  ANY. 

LOCAL  host  indicates  that  the  user  should  not  have  connected 
to  the  datacomputer  via  the  ARPANET.  Effectively#  this 
means  (at  this  time)  that  the  user  is  located  at  CCA  and  is 
connected  to  the  datacomputer  via  a  local  terminal. 

The  host  name  may  also  be  ANY#  which  means  that  any  host# 
foreign  or  local#  Is  acceptable. 

If  a  host  name  Is  not  specified#  the  default  value  Is  ANY. 


User  Name 

The  user  name  is  the  pathname  or  classname  (5)  of  the  login 
node(s)  which  may  gain  access  to  the  node  associated  with 
the  privilege  block.  Note  that  a  different  privilege  block 
must  be  created  for  each  specific  user  permitted  to  use  a 
given  password.  For  example#  if  two  different  users#  say 
CCA. WALDO  and  CCA. DINGLE#  wanted  to  use  the  same  password 
string  CFOO')  to  gain  access  to  a  node#  two  separate  blocks 
would  have  to  be  created#  one  per  specific  user  name.  Thus# 
In  this  example#  one  privilege  block  would  contain  the 
information  CCA.WALDO  ('F00');  the  other# 


(5)  User  classnames  are  defined  below. 
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CCA. DINGLE  ('F00'). 

If  no  user  name  Is  specified,  the  default  Is  **,  which 
grants  any  user  access  to  the  node. 


Sachet 

The  socket  number  Is  a  32-blt  number,  e.g.,  600403,  or  ANY. 
This  Is  an  Identification  number  assigned  by  the  foreign 
host  to  the  user  logged  In  on  that  foreign  host.  Usage  of 
the  socket  number  In  the  CREATEP  statement  ensures  that  only 
specified  users  at  the  foreign  host  site  may  gain  access  to 
a  particular  node. 

Socket  number  defaults  to  ANY. 


Password 

A  password  consists  of  an  alphameric  string  enclosed  by 
single  quote  (')  characters,  e.g.,  P«'F00'.  Non-prlntlng 
characters,  except  blanks,  are  not  valid  In  a  password 
string.  Blanks  may  appear  at  any  point  in  the  quoted 
string.  Tab  characters  are  not  permitted. 

A  privilege  block  need  not  contain  a  password.  In  this 
case,  none  should  be  given  when  referencing  the  node.  Note 
that  xia  password  is  not  the  same  as,  and  Is  Is  treated 
differently  from,  a  mil i  password  (•').  Null  password  Is 
treated  as  a  password  of  zero  length,  and  must  be  supplied 
as  such  whenever  the  node  is  referenced. 


Privilege  £&£  specifications 

The  following  privilege  bits  are  defined  for  0/10: 

LOGIN  (L) 

In  order  to  control  login  identities 
more  closely,  the  ability  to  log  In  to  a 
node  is  not  passed  to  subordinates.  As 
a  result,  -L  (deny  login)  Is 
meaningless. 

CONTROL  (C) 

Control  includes  complete  subordinate 
control  and  privilege  control.  Control 
Is  required  for  creating  and  deleting 
nodes,  file 

s  and  privilege  blocxs.  It 

Is  also  required  for  listing  privilege 
blocks.  It  Is  very  powerful,  and  cannot 
be  removed  by  an  Inferior:  -C  Is  not 
permitted.  After  0/10,  C  may  be  sp'«lt 
Into  meaningful  components. 


Chapter  4: 


Security  and  Passwords 


Page  22 


Data  Control  Privileges 
READ  (R) 

WRITE  (W) 

W  impl I es  R  and  A. 

APPEND  (A) 

A  does  not  imply  R. 

Conflicts  are  not  allowed  in  one  tuple/  e.g. 
+R  and  -R. 


Qr.de ring  Hf  Privi  lece  Blocks 

Utlfi  Of.der.lJlg  £f  orivl lege  blocks  Lfi  important.  When  a  node 
is  referenced/  the  privilege  blocks  (if  any)  for  that  node 
are  scanned  linearly  for  a  password  string  matching  the 
password  entered  by  the  user.  If  a  match  is  found,  the 
user-id  of  the  privilege  block  is  compared  to  the  login 
Identity.  If  they  match/  the  associated  privileges  are 
granted/denied/  and  access  appropriate  to  the  granted 
privilege  set  are  awarded  to  the  node.  If  the  end  of  the 
privilege  blocks  is  reached  without  finding  a 
password/user- i d  match/  the  node  is  opened  with  no 
privi leges. 

Since  the  privilege  blocks  are  scanned  linearly/  their 
ordering  defines  their  selectivity.  For  example/  suppose  a 
node  to  have  two  privilege  blocks  which  specify  the  same 
password  ('foo')  but  different  login  nodes,  say,  A  and  **, 
and  suppose  that  the  block  with  user  name  A  grants  greater 
privileges  (read/write/append)  than  that  with  **  (which 
permits  read).  The  proper  ordering,  as  displayed  by  a 

LIST  WALDO. NODENAME  %PRI V( I  LEGE) ; 
statement,  is  as  follows:  (note  6) 

(1) ,U«A,H»ANY,S»ANY,G«RWA 

(2) ,U«**,H-ANY,S»ANY/G-R  (note  7) 

If  the  order  of  these  blocks  were  reversed,  so  that  the 
block  with  the  user  name  '**'  were  first,  then  whenever  the 
password  FOO  was  encountered  the  first  block  would  be 
selected;  l.e.,  every  login  pathname  would  match  the  '**'« 
and  the  matching  process  would  be  complete.  Thus,  the  block 


(6)  Details  of  this  command  are  given  below. 

(7)  U«**  means  that  any  user  name  will  be  accepted  as  valid. 
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with  the  user  name  A  would  never  be  found,  and  the  user  A 
would  be  unable  to  open  the  node  with  the  greater  privileges 
which  should  be  granted  him. 

In  0/10  the  user  Is  responsible  for  maintaining  the  desired 
search  order,  by  adding  and  deleting  privilege  blocks  via 
their  block  Index  numbers.  The  datalanguage  for  this 
process  Is  described  below.  Future  versions  of  the 
datacomputer  may  provide  an  automatic  ordering  algorithm, 
which  could  be  manually  overridden.  If  desired. 


U.S.e.r.  Classes  (-'Star*  Feature) 

Classes  of  users  may  be  given  access  to  a  '•ode  by  specifying 
a  user  class  as  the  user  nane  instead  of  a  single  user. 
This  Is  done  by  means  of  the  and  '**'  ('star'  and 
'star-star')  features,  if  a  star  appears  In  a  pathname,  it 
Is  interpreted  to  mean:  'any  single  (non-null)  partial 
pathname  Is  acceptable  here'.  That  Is,  if  the  nodes  A.B.N1, 
A.B.N2,  and  A.B.N3  exist  in  the  directory  tree,  usage  of  the 
user  classname  A.B.*  would  specify  any  of  these  three 
pathnames.  Stars  may  appear  at  any  number  of  levels;  for 
example,  if  the  nodes  A.X.N1  and  A.Y.N4  exist,  then  the 
user-name  A.*.*  would  specify  both  of  these  nodes,  as  well 
as  any  of  the  previous  three.  The  use  of  a  star  at  any 
level  implies  that  there  must  be  a  partial  pathname  at  that 
level;  e.g.,  the  classname  A.*.*  could  not  specify  node  A  or 
A.  J . 


User,  Clashes*  eont.  1  '.Siar.-.star..'.  F.eatur.el 

The  use  of  a  single  star  in  a  pathname  indicates  that  a  node 
must  exist  at  the  level  corresponding  to  that  of  the  star, 
and  a  star  must  be  explicitly  specified  for  each  desired 
level.  The  star-star  feature  is  designed  to  permit  access 
to  several  levels  of  nodes.  A  star-star  ('**')  In  a  user 
name  Is  Interpreted  to  mean:  'any  number  (including  zero)  of 
partial  pathnames  are  acceptable  here'.  Thus,  referring  to 
the  example  of  the  preceeding  paragraph,  A.B.N1  could  be 
specified  by  any  of  the  following: 

A.B.N1,** 

A.B.*.** 

A.B.** 

A.*  .** 

A,** 

* .  ** 

** 

For  0/10,  only  trailing  *'s  and/or  a  final  **  are  allowed. 
The  following,  for  example,  are  illegal: 

A,  * .  C 
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A. ** .  C 
A. *. *» . D 
A.**.* 

* .  B . ** 

**  t  * 


Data  language  1&£.  File  Security 

Two  new  datalanguage  statements/  CREATEP  and  DELETEP/  create 
and  delete  privilege  blocks.  They  are  discussed  in  the 
following  sections.  The  list  command  nas  a  new  option/ 
%PRI V  (or  ^PRIVILEGE)/  which  allows  the  user  to  list  the 
privilege  blocks  for  a  node. 

CREATEP  and  DELETEP  are  privileged  requests.  They  are  only 
accepted  when  the  associated  node  can  be  referenced  with 
control  privilege  <C>.  (This  means  that  it  may  be  necessary 
to  login  to  some  particular  node  before  any  privilege  blocks 
can  be  added  to  another/  and  that  passwords  may  be  required 
for  the  login  process  or  for  referencing  nodes  superior  to 
the  node  for  which  the  privilege  block  is  to  be  added.) 


Cr.eatLng  P.r-UtLef.e  Blocks:  createp 

Privilege  blocks  are  created/  and  fully  specified  by#  the 
CREATEP  command.  A  fully  specified  CREATEP  statement  might 
appear  as  follows: 

CREATEP  N00E1('PW1').N0DE2/  U«CCA. WALDO.*.**/  H-34/ 

S*604320/ 

P-'SECRET  PASSWORD'/  G-R/  D«WA/  N-2; 

In  this  example/  the  node  for  which  we  are  creating  a 
privilege  block  is  N0DE1.N0DE2.  We  must  specify  ('PWl')  for 
N0DE1  in  order#  perhaps/  to  gain  control  privileges  at  the 
first  level.  The  parameters  which  follow  the  nodename  is 
the  privilege  keyword  list.  These  are  discussed 
individually  in  the  following  sections/  and  are  summarized 
in  Appendices  A  and  B. 


CREATEP:  User  Name 

The  user  name  is  specie  *  by  'U»'  followed  by  an 
unqualified  pathname  or  classname  string.  The  pathname  may 
have  any  number  of  levels.  It  must  not  contain  password 
strings  for  any  level. 

The  following  are  valid  pathnames/classnames. 

CCA 

CCA. WALDO. DINGLE 
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CCA.* .* 
CCA.** 
*.*.* 

* ,  ** 

** 


CREATEP:  Host  .foupfaen 

ThA  host  number  is  specified  by  ' H* '  followed  by  a  decimal 
number  from  1  to  255,  or  either  of  the  strings  LOCAL  or  ANY. 

Ha28 

H«ANY 

H-LOCAL 


CREATEP:  Socket  Number 

The  socket  number  is  specified  by  'S*'  followed  by  the 
32-bit  foreign-host  assigned  decimal  number  corresponding  to 
the  directory  the  user  is  logged  Into  at  that  foreign  host, 
or  the  string  ANY. 

S-309483 

S-ANY 


CB.EAIEP.;.  Password  String 

The  password  string  is  specified  by  'P*'  followed  by  any 
datacomputer  string  constant  (tabs  may  not  be  included, 
although  blanks  are  permitted),  e.g.,  'PASSWORD  1',  '?  * 

♦♦!!',  or  "  (null  password). 

Note  that  if  no  password  string  is  specified  at  CREATEP 
time,  then  that  privilege  block  will  have  no  password 
associated  with  it.  Jin  password  is  different  from  null 
password  (P»"),  which  Is  a  valid  password  zero  characters 
in  length. 


CREATEP. l  Grant  Edhdle&fiS. 

Privileges  are  granted  by  * G» *  followed  by 
C  (control) 

L  (login) 

R  ( read  f I le  data) 

W  (wr i te  f i le  data) 

A  (append  data  to  fi le) 

in  any  combination  and  in  any  order,  e.g.,  G»CRAWL  (all 
privileges),  G»WAR  (read/write/append),  etc. 


Chapter  4: 


Security  and  Passwords 


Page 


26 


QBEAIER;.  Deny  Prlvl  leges 

Deny  privileges  are  specified  by  'D*'  followed  by  R,  W  or  A. 
Login  (L>  applies  only  to  the  node  for  which  It  Is 
specified,  it  Is  not  passed  to  subordinates.  Control  (C) 
cannot  be  removed  by  any  Inferior  node#  l.e.,  it  Is  passed 
to  all  subnodes. 


fi&EAULE>  Privilege  Block  Index 

As  privilege  blocks  are  created,  they  are  assigned  Index 
numbers  by  the  datacomputer.  Block  numbers  are  assigned  to 
privilege  blocks  sequentially  according  to  their  search 
order.  Block  numbers  can  range  from  one  to  n,  where  n  Is 
the  total  number  of  password  blocks  In  the  search  sequence. 
Blocks  can  be  explicitly  ordered  by  the  user  at  CREATEP  time 
by  entering  'N*'  followed  by  the  number  that  the  newly  added 
block  Is  to  have  In  the  search  sequence.  N  must  be  greater 
than  zero,  and  not  greater  than  the  total  number  of 
privilege  blocks  currently  existing  for  the  node.  Note  that 
this  Index  Is  not  In  any  sense  a  part  of  the  data  contained 
In  the  privilege  block;  It  Is  merely  the  position  of  the 
block  in  the  password  block  list. 

An  example.  If  there  were  three  blocks  In  the  privilege 
block  list  for  a  node  (N0DE1), 

1  U-AAA 

2  U-CCC 

3  U-DDD 

and  a  new  block  were  to  be  added  between  the  first  and 
second  existing  blocks,  l.e.,  so  that  the  new  block  would 
then  occupy  second  position,  we  add  a  keyword,  N«2,  to  a 
CREATEP  command: 

CREATEP  N00El,U-BBB,P-'Z00,,N-2; 
which  results  In  the  following  privilege  block  list: 

1  U*AAA 

2  U-BBB 

3  U=CCC 

4  U*DDD 

If  N  had  been  omitted,  the  new  block  would  have  been  added 
at  the  end  of  the  list.  Note  that  the  Indices  of  the  two 
blocks  following  the  new  one  have  been  bumped  by  one. 
Similarly,  If  any  block  Is  deleted,  the  Indices  of  all  the 
following  blocks  are  reduced  by  one. 
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Looking  £1  Privilege  Blocks;  LIST 

in  order  to  permit  the  user  to  list  privilege  block 
Information/  the  IfcPRiV  (or  ^PRIVILEGE)  option  has  been  added 
to  the  data  language  LIST  request,  it  looks  like  this: 

LIST  CCA. WALDO  *PRiV  (or) 

LIST  CCA. WALDO  ^PRIVILEGE 

Passwords  cannot  be  listed  with  the  iPRIV  option  (or  in  any 
other  way  -  so  don't  forget  'em!).  Privilege  block 
information  is  preceeded  by  the  Index  rubber  of  that  block. 
All  other  Information  In  the  privilege  block  is  listed  In  a 
format  similar  to  that  which  might  be  found  in  a  CRFATEP 
command/  e.g,  either  of  tn^  LIST  requests  above  might 
generate  the  following  output  from  the  datacomputer : 

( 1)  /U*CCA.WALDO/H-LOCAL/S«ANY/G«CRAWL 

(2) /U«CCA.*.**/H-ANY/S«ANY/G»RWAL 

( 3)  / U** . **/H*32/ S*654364#  G*RL/D*WA 

%PRIV  may  be  used  only  when  the  controlling  node  has  control 
pri vi leges. 


aeletLng  El U Liege  a  locks:  deletep 

Privilege  blocks  may  be  deleted  with  DELETEP  followed  by  the 
Index  number  of  the  privilege  block  to  be  deleted/ 

DELETEP  3 

The  controlling  node  must  have  control  privilege. 
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This  example  will  create  a  node  which  will  be  the 
controlling  node  for  *  all  other  nodes  at  site  CCA. 
Presumably,  access  to  this  controlling  node  would  be 
restricted  to  very  few  persons  at  that  site;  'super-users', 
as  it  were.  This  could  be  done  by  means  of  a  password.  in 
addition,  anyone  seeking  control  privileges  for  CCA  might  be 
required  to  be  logged-in  to  seme  other  (access  restricted) 
node.  The  person  with  access  to  CCA  would  be  responsible 
for  creating  subnodes,  perhaps  one  for  each  programmer 
permitted  to  use  the  datacomputer.  These  individual 
programmers  could  then  create  their  own  directory  structures 
(nodes,  ports  and  files)  in  any  manner  they  wish. 

The  site-node  CCA  is  created  by  the  following  series  of 
requests: 

CREATE  CCA; 

CREATEP  CCA,P-'HGNCHO',G-CL; 

CREATEP  CCA, P-' FLUNKY ' ,G*L; 

LOGIN  CCA( 'HONCHO'); 

The  user  is  now  logged  in  to  CCA.  He  has  control 
privileges.  Next  he  creates  a  series  of  programmer-nodes, 
each  wi th  control  privileges.  Initially,  two  privilege 
blocks  are  created  for  each  programmer  node.  One  requires  a 
password  (known  to,  and  probably  specified  by,  the 
individual  programmer),  and  the  other  requires  no  password 
and  is  accessible  to  anyone  logged  in  to  CCA  or  any  of  its 
subnodes.  However,  persons  who  log  in  to  a  programmer  node 
without  specifying  a  password  are  not  given  control 
privileges  and  thus  cannot  modify  or  delete  anything  that 
the  programmer  wishes  to  keep  secure. 

CREATE  WALDO;  CREATEP  WALDO, U-CCA, P-'TURKEY' ,G-CL; 

CREATEP  WALDO, U-CCA. **,G-L; 

CREATE  CLYDE;  CREATEP  CLYDE, U-CCA, P-' FETCH ', G-CL; 

CREATEP  CLYDE, U-CCA. **,G-L; 


CREATE  DINK;  CREATEP  Dl NK, U-CCA, P-' POPUNK' ,G-CL; 
CREATEP  DINK, U-CCA. **,G-L; 

After  this  is  done,  super-user  checks  the  privilege  blocks 
he  has  created,  first  at  his  own  node  level: 

LIST  HOP. CCA( 'HONCHO')  ^PRIVILEGE; 
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and  he  receives  a  datacomputer  printout  in  the  following 
format: 


(1) ,U»**,H«ANY,S»ANY,G«CL 

(2) ,U»**,H«ANY,S«ANY,G«L 

He  next  verifies  that  each  of  the  programmer-node  privilege 
blocks  has  been  correctly  entered,  e.g., 

LIST  WALDO  *PRIV; 

and  the  datacomputer  replies: 

(1) ,U«CCA,H-ANY,S-ANY,G«CL 

(2) ,U»CCA.**,H-ANY,S«ANY,G«L 

At  this  point,  programmer  Waldo  tells  super-user  that  he 
would  rather  have  'donkey*  as  his  control  password  rather 
than  'turkey'.  Since  the  user  name  (U*CCA)  In  Waldo's 
control  privilege  block  is  more  restrictive  than  the  user 
name  (U«CCA.**)  In  the  non-control  privilege  block,  the 
first  privilege  block  must  be  deleted  and  the  new  one  added 
In  the  same  position  (N«l): 

DELETE  WALDO  1; 

CREATEP  WALDO, U “CCA, PB 'DONKEY ' ,G=CL,N*1; 

We  now  have  the  following  directory: 

CCA 

CCA. WALDO 
CCA. CLYDE 


CCA. DINK 

Each  of  the  programmer-nodes  listed  above  has  its  own 
password  which  Is  known  to  the  person  having  access  to  that 
node.  In  addition,  each  is  required  to  login  to  CCA  befot e 
being  able  to  acquire  login  and  control  privileges  at  > ts 
own  level.  (Most  or  all  of  the  programmers  at  CCA  are  given 
only  the  password  FLUNKY,  which  does  not  give  control 
privileges.  Thus,  they  cannot  create  or  delete  any  nodes  at 
the  programmer-node  level  or  look  at  the  restricted  data  of 
any  other  programmers. ) 

As  soon  as  he  is  informed  that  lie  may  join  the  select 
international  hoard  of  datacomputer  users,  Waldo  rushes  to 
his  terminal  to  login: 


LOGIN  CCA( 'FLUNKY'); 
LOGIN  WALD0( 'DONKEY'); 
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Since  he  has  logged  in  to  his  node  using  the  password  which 
grants  control  privileges,  Waldo  now  creates  BOOKFILE  and 
BOOKPORT  and  reads  some  data  Into  BOOKFILE  from  a  TENEX  file 
named  TENEX-B00K. FI LE  (note  8): 

CREATE  BOOKFILE  FILE  LI ST( , 1000) , P-EOF 
BOOK  STRUCT 

TITLE  STR  (,100),C-1 
AUTHORS  LI ST( , 5) , C*1 
AUTHOR  STR  (,50),C-1 
PUBLISHER  STR  (,50),C-1 

RE¬ 
CREATE  B00KP0RT  PORT  L I ST( , 1000) , P=EOF 
BOOK  STRUCT 

TITLE  STR  (, 100) , P*EOR 
AUTHORS  LIST(,5),P«EOB 
AUTHOR  STR  (,50),P-EOR 
PUBLISHER  STR  (,50),P-EOR 

END; 

CLOSE  SOPEN; 

OPEN  BOOKFILE  WRITE; 

OPEN  BOOKPORT;  CONNECT  BOOKPORT  'TENEX-BOOK. FI LE' ; 

(NOTE  8) 

BOOKFI LE-BOOKPORT; 

CLOSE  ?OPEN; 

In  order  to  permit  others  to  look  at  his  library  file,  Waldo 
creates  a  couple  of  privilege  blocks.  The  first  permits 
anyone  at  CCA  to  look  at  his  book  list,  while  denying  him 
the  right  to  change  anything.  The  second  Is  for  Waldo's 
private  use  In  changing  the  file; 

CREATEP  BOOKFI LE,U»CCA. *, G»R,D»AW; 

CREATEP 

BOOKFI LE,U-CCA. WALDO, P- 'READ*MORE*EVERY*DAY ' ,G-RWA; 


(8)  A  TENEX  filename  is  used  in  this  example  for  the  purpose 
of  didactic  clarity.  in  practice,  this  would  usually  be 
done  only  by  local  datacomputer  users  (users  located  at  the 
site  of  the  datacomputer).  Remote  users  would  have  to 
arrange  for  operator  intervention,  if  connecting  to  a  file 
at  the  datacomputer  site;  or  would  specify  the  host  name  and 
socket  number  from  which  the  dats  would  be  sent  to  the 
datacomputer. 


Pace  31 


Chapter  5:  Assignment  and  For-loops 


Assignment  Involving  Outermost  Containers 

Transmission  of  data  Is  achieved  with  an  assignment. 

7he  syntax  of  an  assignment  request  that  Involves  two 
outermost 
containers  Is 

<!dent>  *  <Ident>; 

where  the  <!dent>s  are  the  node  names  of  opcr,  outermost 
containers.  The  first  Ident  In  the  statement  Is  that  of  the 
receiving  container;  It  must  be  open  In  either  WRITE  or 
APPEND  mode.  The  second  Ident  Is  that  of  the  transmitting 
container;  It  can  be  open  In  any  mode,  but  It  must  have  READ 
privilege  (see  Chapter  4). If  the  second  ident  Is  a  FILE,  It 
must  contain  some  data. 

The  containers  In  the  assignment  may  be  either  flies  or 
ports.  The  various  combinations  are  listed  here,  with  a 
description  of  the  action  of  the  assignment  request  In  each 
case. 


Recelv'ng  Transmitting  Comment 

container  container 


FILE 

FILE 

copies  data  from  one  FILE  to  another 
within  the  datacomputer. 

FILE 

PORT 

transml ts  data  from  some  source 
external  to  the  datacomputer  through 
a  PORT,  into  a  FILE. 

PORT 

FILE 

transmits  data  from  a  FILE,  where  It 
Is  being  kept  in  the  datacomputer, 
through  a  PORT,  to  the  outside  world 

PORT 

PORT 

transmits  data  from  one  place  to 
another  In  the  outside  world,  using 
the  datacomputer  only  as  a  channel 
for  transmission. 

Matching  Rules 


In  any  assignment  statement  such  as 
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X  -  Y; 

(not  only  one  involving  two  outermost  containers)  the  two 
operands^  X  and  Y/  each  has  its  own  description.  The 
datacomputer  win  transform  the  data  in  Y  to  match  the 
description  of  X.  In  order  for  the  datacomputer  to  be  able 
to  do  this/  the  descriptions  must  match.  This  amounts  to  a 
restriction  that  only  similar  objects  can  be  assigned  to 
each  other.  Specifically/  for  two  assignment-operands  X  and 
Y  to  match: 

l.A.  X  and  Y  must  have  the  same  type:  LIST/  STRUCT/  or 
STR/  or  BYTE/ 

AND 

l.B.  if  X  and  Y  are  both  LISTS/  then  they  must  have 
compatible  sizes,  or  else  X  must  be  a  PORT.  The  sizes  are 
compatible  if  the  minimum  size  of  X  is  less  than  or  equal  to 
the  minimum  of  Y  and  the  maximum  size  of  X  is  greater  than 
or  equal  to  the  maximum  size  of  Y.  This  restriction  leads 
to  cases  where  it  is  legal  to  assign  Y  to  X  but  not  to 
assign  X  to  Y.  Note  that  If  X  and  Y  are  outermost  lists 
with  no  list  size  specified/  the  datacomputer  supplies  a 
default  size  based  on  the  space  allocation,  (use  the  LIST 
request  with  the  $DESC  option  to  find  out  what  the  default 
size  is.) 

AND 

1. C.  If  X  and  Y  are  STRUCTs  or  LISTs,  then  at  least 
one  container  immediately  enclosed  in  X  must  match,  and  have 
the  same  ident  as.  one  container  Immediately  contained  In  Y/ 

OR 

2.  X  must  be  a  STRing  and  Y  a  constant.  A  constant  is 
an  arbitrary  string  of  characters.  If  they  are  enclosed  by 
single  quote  marks/  then  is  is  an  ASCII  constant;  a  single 
or  double  quote  mark  may  be  included  in  such  a  string  only 
by  prefixing  it  with  another  double  quote.  The  constant 
’DON" *T*  represents  the  string  DON'T.  (This  rule  Is 
Included  here  for  completeness  and  will  be  discussed  later.) 


Padding  £04  Truncation 

if  two  containers  of  type  STR  are  used  in  an 
assignment/  the  matching  rules  do  not  require  that  their 
sizes  match.  There  are  three  cases: 

1.  The  two  sizes  are  equal.  The  string  is  assigned 
without  change. 

2.  in  the  assignment  X*Y/  the  size  of  X  Is  greater 
than  that  of  Y.  In  this  case/  it  is  as  if  the  string  in  Y 
Is  padded  at  the  right-hand  side  to  make  It  as  long  as  X/ 
before  assignment  Is  performed.  If  a  fill  character  is 
specified  in  the  description  of  X  (i.e.  If  the  parameter 
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,F^'a'  or  .  F-n  Is  used  In  the  CREATE  request),  then  that 
character  Is  jsed.  Otherwise,  a  blank  Is  used  for  ASCII 
strings  and  zero  is  used  for  non-AscII  data. 

3.  The  size  of  X  is  less  than  that  of  Y.  The  string 
contained  in  Y  is  truncated  at  the  right-hand  side  to  be  as 
short  as  X,  and  the  shortened  string  Is  then  assigned. 


Ex*mo1 ps 

Let  us  consider  a  few  examples  of  the  operation  of  the 
rules.  Suppose  we  have 

CREATE  M  FILE  LIST  (25),  P-EOF  RECORD  STR(IO); 

CREATE  N  TEMP  PORT  LIST  (25),  P-EOF  RECORD  STR(IO)  ; 

M  -  N; 

where  M  Is  a  FILE  In  which  data  read  from  the  PORT  N  Is  to 
be  stored  in  the  datacomputer .  The  assignment  M  *  N  Is 
legal  because  M  Is  in  WRITE  mode  and  both  M  and  N  are  open 
(opened  by  the  CREATE  statements).  In  addition,  M  and  N 
match:  their  subcontainers  have  the  same  ident  (RECORD),  and 
matching  descriptions.  They  satisfy  rule  l.A,  since  the 
type  Is  STR  In  both  cases,  and  rules  l.B  and  l.C  do  not 
apply  to  containers  of  type  STR. 

The  effect  of  this  assignment  Is  to  read  strings  of 
length  10  from  the  PORT  N,  and  to  store  them  In  the  FILE  M. 
If  an  attempt  Is  made  to  store  more  than  25  strings  In  M, 
the  datacomputer  will  complain,  as  space  was  allocated  for 
only  25  strings.  However,  the  25  In  the  PORT  description  Is 
Ignored. 

A  similar  example,  using  the  above  description  for  M: 

OPEN  M  APPEND; 

CREATE  0  TEMP  PORT  LIST,  P-EOF 

RECORD  STR  (,15),  P-EOR  ; 

M  -  0; 

Each  STRing  in  0  is  no  more  than  15  ASCII  characters  and 
ends  with  an  EOR.  Each  one  will  be  padded  or  truncated  to 
10  characters  since  M  has  fixed-length  rather  than 
punctuated  STRIngs. 

Now  a  more  complex  example. 

CREATE  FF  FILE  LIST  (25),  P-EOF 
PERSON  STRUCT 
NAME  STR  (15) 

ADDRESS  STR  (20) 

CITY  STR  (10) 

STATE  STR  (2) 

ZIP  STR  (5) 
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SOCSECNO  STR  (10) 

DEPENDENTS  LIST  (10)  NAME  STR  (15) 

END  ; 

...  requests  that  store  data  in  the  FILE  FF  ... 

CREATE  PP  PORT  LIST#  P-EOF 
PERSON  STRUCT#  P-EOR 
NAME  STR  (15) 

SCCSEfNO  STR  (10) 

END; 

PP  -  FF  ; 

Here#  the  assignment  PP  ■  FF  Is  legal  because:  PP  Is  In 
WRITE  mode/  both  FF  and  PP  are  open/  and  their  descriptions 
match.  Rule  l.A:  the  type  of  both  FF  and  PP  Is  LIST.  Rule 
l.B:  PP  Is  a  PORT.  Rule  l.C:  the  subcontainer  PERSON 
immediately  contained  In  FF  has  the  same  Ident  as  PP. PERSON/ 
and  the  two  STRUCTs  PERSON  match.  We  determine  this  last 
fact  by  going  round  once  again  with  the  matching  rules. 

Rule  l.A:  FF. PERSON  and  PP. PERSON  have  the  same  type, 
STRUCT.  Rule  l.B  does  not  apply  to  STRUCTs.  Rule  l.C:  a 
container  Immediately  contained  in  FF. PERSON, 
FF. PERSON. NAME,  has  the  same  ident  (NAME)  and  a  matching 
description  (STR  (15))  as  a  container  immediately  enclosed 
by  PP. PERSON,  that  Is,  PP. PERSON. NAME. 

The  effect  of  this  assignment  is  to  create  a  new 
Instance  of  the  struct  PP. PERSON  for  each  instance  of  PERSON 
In  FF#  and  add  It  to  the  LIST  PP  (that  Is,  output  It  through 

the  PORT  PP).  Each  PERSON  that  Is  output  contains  only  a 

selection  of  the  data  stored  In  FF:  only  the  NAME  and 

SOCSECNO. 

If  the  situation  here  were  reversed,  that  Is,  If  FF 
were  open  In  WRITE  mode,  and  PP  were  In  READ  mode,  the 
effect  of  the  assignment 

FF  «  PP; 

would  be  to  read  data  from  the  PORT  PP  and  store  It  In  the 

FILE  FF.  However,  only  the  NAME  and  SOCSECNO  would  be 

available  as  data.  The  datacomputer  handles  this  situation 
by  assigning  strings  consisting  only  of  blanks  (the  default 
since  no  fill  character  Is  specified  in  the  description)  to 

the  unmatched  STRs  In  the  output  LIST-member.  Thus, 

ADDRESS,  CITY,  STATE,  ZIP,  and  all  10  Instances  of 

DEPENDENTS. NAME  would  be  blank  in  the  FILE  FF. 


Very  often,  assignment  at  the  level  of  outermost 
containers  is  all  that  a  user's  program  will  require  of  the 
datacomputer.  An  example  would  be  a  time-sharing  monitor 
system,  which  might  want  to  store  backup  files,  large  files, 
or  infrequently-used  files  at  the  datacomputer  rather  than 
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locally  on  (expensive)  disc  storage  devices.  Typically/ 
such  a  monitor  system  would  Itself  keep  track  of  where 
various  files  resided/  and  move  them  from  place  to  place 
over  the  ARPA  network  without  burdening  its  users  with  the 
details  of  exactly  where  their  files  were  stored. 

For  such  an  application/  a  directory  might  be  set  up 
with  one  node  identifying  the  operating  system  that  is  doing 
the  file  storage.  Subordinate  to  this  node  might  be  the 
use**  idents  of  its  various  time-sharing  users  whose  files 
might  be  stored  on  the  datacomputer .  These  user  nodes/  in 
turn/  would  have  the  file-names  themselves  as  subordinate 
nodes;  as  bottom-most  nodes/  these  would  also  be  outermost 
containers  and  thus  could  store  the  data  itself.  As  a 
diagram: 


Figure  5-3.  The  directory  for  a  sample  application: 
providing  backup  file  storage  for  time-sharing  users 


A  directory  of  this  sort  would  initially  be  set  up  by 
several  CREATE  requests;  l.e. 

CREATE  SYS87; 

CREATE  SYS87.SAM;  CREATE  £VS87. SMITH; 

CREATE  SYS87. JONES;  etc. 

Then#  whenever  a  particular  file  was  to  be  moved  to  the 
datacomputer/  a  directory  node  for  that  file  would  be  set  up 
by#  for  example/ 

CREATE  SYS87.SMITH.FI LEI  FILE  LIST  (999) 

A  STR( 80 ) ; 
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(describing  a  file  with  less  than  1000  80-character  records) 
and  the  file  would  be  moved  with  an  assignment  stJtement 
specifying  a  PORT  with  a  matching  description,  and  the  FILE 
FiLEl,  open  in  WRITE  mode.  Thus: 

CREATE  T  TEMP  PORT  LIST  A  STR180); 

FI  LEI  -  T; 


Note  that  the  two  outermost  containers  FI  LEI  and  T  in 
the  assignment  statement  FI  LEI  ■  T  match  each  other. 

In  order  to  recover  the  file  from  the  datacomputer  when 
it  is  again  needed,  a  PORT  would  be  opened  in  WRITE  mode 
wi  th 

CREATE  T  TEMP  PORT  LIST  A  STR(80); 

OPEN  SYS87.SMITH.FI LEI  READ; 

T  «  FI  LEI  ; 

and  the  reverse  assignment  would  teke  place. 


Selefi.tl.Qn  Q±  LLST  Members 


In  the  examples  given  above,  there  Is  one  output  LIST 
member  for  every  Input  LIST  member.  Subsets  of  the  Input 
LIST  member  (i.e.  the  LIST  on  the  right  side  of  the  -)  may 
be  specified  by  the  use  of  WITH  clause  as  an  input-spec. 
For  example,  consider  the  description 

CREATE  F  FILE  LIST,  P-EOF 

P  STRUCT  A  STR( 3)  B  STR(5)  END; 

and  a  matching  PORT  R.  if  only  some  of  the  P's  on  the  LIST 
F  were  to  be  output  --  those  with  the  string  A  equal  to  the 
string  '500',  say  --  one  could  specify 

R  »  F  WITH  A  EQ  '500'; 

referring  to  the  set  of  all  members  P  of  the  LIST  F  that 
have  the  given  property.  Note  that  A  is  understood  to  refer 
to  F.P.A;  see  the  section  on  the  context  rules  below  for  an 
explanation.  Quotes  are  used  in  the  expression  *500'  to 
indicate  tnat  an  ASCII  string  constant  is  intended. 

In  a  WITH  clause,  the  expressions  one  can  use  to  choose 
certain  LIST-members,  which  are  called  Boolean  expressions, 
must  Involve  comparison  of  a  container  that  is  a  STR  or  BYTE 
with  a  constant  (like  '500'  In  the  example),  using  the 
comparison  operators 
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and 


EQ  (equals) 

NE  (not  equal  to) 

GT  (greater  than) 

LT  (less  than) 

GE  (greater  than  or  equal  to) 
LE  (less  than  or  equal  to). 


Combinations  of  comparisons  with 


OR,  AND,  NOT,  and  ANY 

are  also  possible.  In  precedence  of  operators,  ANY  (see 
below)  is  highest;  NOT  is  next  in  precedence,  then  AND, 
which  is  in  turn  higher  than  OR;  parentheses  may  be  used  to 
affect  the  order  of  evaluation  of  these  operators. 

When  using  an  input-spec,  the  name  of  the  input 
LI ST-member  may  be  used  instead  of  the  name  of  the  input 
LIST.  (This  is  for  consistency  with  the  syntax  of  the 
FOR-loop,  discussed  below.)  Thus, 

R  -  F.P  WITH  A  EQ  '500'; 

is  equivalent  to  the  example  above.  Some  sample  input-specs 
are  thus: 


F.P 

F.P  WITH  A  EQ  '500' 

F  WITH  A  EQ  '500'  ANO  B  GT  'AZZZZ' 

F.P  WITH  (A  EQ  r  500’  AND  NOT  B  GT  'MONDA')  OR 
(A  EQ  '600’  AND  B  NE  'ZYYYY ' ) 

For  ASCII  containers,  the  operators  GT,  LT,  etc.  compare 
the  ASCII  codes  for  the  given  strings  and  the  given  strings 
must  be  of  the  specified  length.  This  means  that  the 
character  blank  is  less  than  the  digits,  which  in  turn  are 
less  than  the  letters.  Consult  a  reference  document  for  the 
complete  list  of  ASCII  codes  for  all  characters. 

Also,  while  an  input-spec  like 

F.P  WITH  A  EQ  '5' 

is  legal,  it  will  not  find  any  P's,  since  there  are  no  A's 
with  only  one  character. 


Retrievals  HsJLae.  Inner  List  Members 

Consider  a  description  like 

G  FILE  LIST,  P-EOF 
R  STRUCT 
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A  STR  (4) 

B  STR  (4) 

W  LIST  (20) 

WA  STR  (5) 

END 

Each  R  has  20  Wa's,  since  R  contains  an  inner  list  (W).  An 
input-spec  like 

G.R  WITH  WA  EQ  1 ABCDE ' 

specifies  ail  R's  with  at  least  one  Wa  with  value  'ABCDE'. 
This  may  also  be  expressed  as 

G.R  WITH  ANY  WA  EQ  'ABCDE' 

The  former  Is  called  an  implicit  ANY  and  the  latter,  an 
explicit  ANY. 

The  container  WA  can  be  used  In  boolean  expressions 
such  as 


G.R  WITH 

ANY  (WA  EQ  'MARCH'  AND  WA  EQ 

'33103') 

G.R  WITH  ANY 

(WA  EQ  'MARCH'  OR  WA  EQ  'WORD  ') 

G.R  WITH  ANY  WA  EQ  '12345'  AND  B  EQ  'CALI' 
An  ANY  expression  cannot  be  used  within  the  object  of 
another  ANY  expression  (nested  ANY's). 


In  most  cases,  the  explicit  ANY  is  not  required. 
However,  consider  the  description: 

FAMILIES  FILE  LIST  (100),  P-EOF 
FAMILY  STRUCT 

MOTHER  STR  (10) 

FATHER  STR  (10) 

CHILDREN  LIST  (10) 

CHILD  STRUCT 

NAME  STR  (,10),  C-l 
AGE  STR  (2) 


The  following  expressions  are  not  equivalent: 

FAMILY  WITH  ANY  (CHILD. NAME  EQ  'ELLEN'  AND 
CHILD. AGE  EQ  '21') 

FAMILY  WITH  CHILD. NAME  EQ  'ELLEN'  AND 
CHILD. AGE  EQ  '21'. 
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The  latter  case  Is  Interpreted  as: 

FAMILY  WITH  ANY  CHILD. NAME  EQ  'ELLEN' 

AND  ANY  CHILD. AGE  EQ  '21' 

and  refers  to  any  FAMILY  with  an  ELLEN  who  either  Is  21  or 
has  a  sibling  who  is  21.  The  former  only  refers  to  FAMILYs 
with  a  21-year-old  ELLEN. 

In  all  of  these  examples,  the  Inner  list  Is  the 
second-level  list.  If  there  Is  a  third  level  list.  Its 
members  may  not  be  used  in  a  boolean  expression.  For 
example,  given  the  description: 


F  FILE  LIST  R  STRUCT 
A  STR(l) 

L  LIST  (5) 

LI  LIST  (5) 

B  STR  (1) 

END; 


LI  Is  a  third-level  list,  and  so  B  cannot  be  used  In  a  WITH 
expression.  However,  A  may  still  be  used  In  a  WITH 
expression. 


Rate  Leya IS  Using  Inverted  Containers 

A  STR  may  be  I nverted  If  It  Is  contained  In  a  FILE 
which  Is  a  LIST  and  If  the  LIST  members  are  fixed-size. 
This  Is  useful  If  the  STR  will  be  used  often  In  a  boolean 
expression.  Inversion  Is  specified  by  MI»D"  or  "l**l"  as 
fol lows: 

CREATE  F  FILE  LIST  (0,100),  P-EOF 
P  STRUCT 
A  STR  (3),  l-D 
Q  LIST  (10) 

B  STR  (5),  1-1 
END; 

The  "I"  of  the  above  stands  for  Inversion,  the  "■D"  is  used 
with  members  of  outer  lists,  the  "■!"  with  inner  lists. 

An  inversion  on  the  string  A  greatly  increases  the 
efficiency  of  retrieving  sets  of  outermost-LIST  members  by 
the  contents  of  the  string  A  --  that  Is,  retrieving  subsets 
of  the  P's  that  are  defined  by  their  values  of  A.  Retrieval 
by  content  based  on  a  particular  string  Is  possible  whether 
or  not  that  string  Is  Inverted;  only  the  efficiency  is 
Improved  by  the  existence  of  an  inversion  on  the  string. 

There  is  a  certain  cost  associated  with  inversion, 
however.  storage  space  must  be  allocated  for  a  secondary 
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data  structure  that  the  datacomputer  uses  for  retrievals 
based  on  Inverted  strings.  Updating  a  FILE  takes  longer 
when  It  Is  Inverted,  since  the  secondary  data  structure  must 
be  updated  as  well.  Thus,  the  decision  to  Invert  a 
particular  string  will  depend  on  the  relative  cost  of 
Increased  retrieval  time  versus  Increased  storage  space,  the 
frequency  of  retrieval  based  on  the  particular  string,  and 
other  considerations.  Appendix  C  contains  further  technical 
details  concerning  Inversion. 


Assignment  wi-th  JLQ& 

Containers  that  are  not  outermost  can  also  be  used  In 
assignment  statements.  With  FOR,  assignments  that  retrieve 
subsets  of  LIST-members  may  be  performed.  In  contrast  with 
assignment  of  outermost  containers.  FOR  causes  some  set  of 
datalanguage  statements  (usually  assignment  statements)  to 
be  executed  several  times,  once  for  each  member  of  a  given 
set  of  LIST-members. 

The  syntax  of  the  FOR-request  is: 

FOR  <output-spec>,  <lnput-spec>  <body>  END  ; 

The  <lnput-spec>  specifies  a  set  of  LIST-members  to  which 
the  operations  specified  In  the  <body>  are  to  be  applied.  A 
new  member  of  the  LIST  specified  by  the  <output-spec>  Is 
created  for  each  member  of  the  Input  set  processed.  If  the 
output-spec  Is  omitted,  the  FOR-request  generates  no  output. 

The  Inout-soec  The  Input-spec  must  specify  a  set  of 
LIST-members.  The  simplest  kind  of  Input-spec  Is  just  an 
entire  LIST  --  l.e.  the  set  of  all  the  LIST-members. 
However,  the  name  of  the  LI ST-member  and  not  the  LIST  Itself 
must  be  given.  For  example,  if 

CREATE  F  FILE  LIST,  P-EOF 

P  STRUCT  A  STR  (3)  B  STR  (5)  END; 

then  F.P  would  be  a  legal  Input-spec,  and  would  refer  to  the 
set  of  all  P's  In  the  LIST  F. 


A  subset  of  the  LIST-members  may  be  specified  by  the 
use  of  a  WITH  clause  In  the  Input-spec.  The  Input-spec  on  a 
FOR-loop  looks  like  the  Input  spec  on  the  assignment  of 
outermost  containers  (discussed  above),  except  that  the 
LI ST-member  must  be  named  rather  than  the  LIST.  Thus 


F.P  WITH  A  EQ  '500' 
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can  be  used  in  a  FOR-loop#  but  not 
F  WITH  A  EQ  '500’ 

The  ou tout-spec  The  output-spec  Is  an  optional 
argument.  Like  the  input-spec#  it  must  be  the  name  of  a 
LIST-membe  .  The  LIST  that  contains  the  LIST-member 
specified  by  the  output-spec  is  often  called  the  output 
LI  ST.  A  new  member  Is  created  and  added  to  the  output  LIST 
for  each  execution  of  the  FOR-body. 

A  FOR-loop  may  be  loosely  thought  of  as  assignment 
between  two  LISTs.  However#  the  descriptions  of  the  members 
of  the  Input  and  output  LISTs  need  not  match.  Otherwise# 
the  restrictions  governing  the  input  and  output  LiSTs  of  a 
FOR  are  largely  the  same  as  those  governing  outermost  LiSTs 
used  in  assignment: 

1.  Both  LiSTs  must  be  open  or  contained  In  open 
outermost  containers. 

2.  If  the  output  LIST  is  an  open  outermost  container# 
It  must  be  In  WRITE  or  APPEND  mode. 

3.  If  the  Input  LIST  Is  not  an  outermost  container# 
the  LIST  that  most  immediately  encloses  it  must  be  the  Input 
LIST  of  an  enclosing  FOR  loop. 

4.  Similarly#  if  the  output  LIST  is  not  outermost#  the 
LIST  that  most  immediately  encloses  it  must  be  the  output 
LIST  of  an  enclosing  FOR, 

The  FQR-bodv  The  operations  that  are  legal  In  a 
FOR-body  are  assignment  and  another  (nested)  FOR.  The 
assignment  may  be  of  the  form 

<name>  ■  <constant>  # 

where  <name>  refers  to  a  container  that  Is  a  STR  (see 
matching  rule  number  3)#  or  assignment  may  be  of  the  form 

<name>  *  <name>; 

to  transfer  data  from  one  container  to  another.  If  the 
latter  is  the  case#  then  assignment  is  subject  to 

1.  the  restrictions  specified  in  the  matching  rules 
above# 

2.  the  usual  restriction  that  data  can  be  transmitted 
Into  a  container  only  if  it  is  open  in  WRITE  or  APPEND  mode# 
and 

3.  the  restriction  that  assignment  must  occur  between 
q bifida /  not  sets  s£  objects. 

4.  In  Version  0/10  of  datal anguage#  there  are  other 
restrictions  governing  the  containers  that  can  be  referenced 
in  the  body  of  a  FOR-loop.  See  Appendix  E. 
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Let  us  look  at 
operation  in  words. 


a  few  examp les,  and  describe 
With  F  a  FILE  as  above/  and 


their 


then 

and 


CREATE  Q  FILE  LIST 
P  STRUCT 

A  STR  (3) 

B  STR  (5) 

END; 

OPEN  F  WRITE; 

F  ■  Q; 

FOR  F.P/  Q.P 
F.P  -  Q.P  ; 

END; 


have  the  same  effect:  a  new  member  P  is  created  and  added  to 
the  LIST  F. 


L i kewi se 

FOR  F.P/  Q.P  WITH  A  EQ  *  500  * 

F.P  -  Q.P; 

END; 

HAS  THE  SAME  EFFECT  AS 

F  -  Q.P  WITH  A  EQ  ’500' 

A  final  example:  with  FF. PERSON  and  PP. PERSON  as  given 
in  the  example  for  the  matching  rules, 

FOR  PP. PERSON,  FF. PERSON  WITH  STATE  EQ  *RI ' 

OR  STATE  EQ  'CT'  OR  STATE  EQ  'MA' 

OR  STATE  EQ  'VT'  OR  STATE  EQ  'NH' 

OR  STATE  EQ  'ME' 

PP. PERSON. NAME  ■  FF . PERSON. NAME; 

END; 

will  have  the  effect  of  outputting  through  the  PORT  PP,  the 
NAMEs  of  all  PERSONS  in  the  FILE  FF  who  live  in  New  England; 
i.e.  with  STATE  equal  to  one  of  the  New  England  states. 
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We  proceed  now  from  the  basics  of  the  language  Itself, 
such  as  containers  and  assignment,  to  a  hroader  view  of  how 
datalanguage  might  be  employee  by  a  user's  program.  We  will 
discuss  such  matters  as  accessing  the  datacomputer, 
transmitting  data  to  and  from  datalanguage  PORTs,  and 
various  aids  to  the  maintenance  of  data  and  FI  I.E  and  PORT 
descriptions  on  the  datacomputer. 


Interacting  wi  th  the  PfltaCOPIPUtsr 

Typically,  datalanguage  requests  will  be  sent  to  the 
datacomputer  by  a  user  program  residing  on  some  computer  on 
the  ARPA  network.  All  interaction  between  the  user  program 
and  the  datacomputer  takes  place  over  the  network. 

Information  transmission  over  the  network  takes  place 
along  un i -d I rect I onal  paths.  For  a  two-way  conversation, 
two  such  paths  are  needed,  one  for  transmission  in  each 
direction.  The  end  of  a  transmission  path  Is  called  a 
<iockt>t :  a  socket  can  be  either  a  send  (output)  or  receive 
(Input)  socket.  Obviously,  a  transmission  path  requires  a 
send  socket  at  one  end  and  a  receive  socket  at  the  other.  A 
diagram  of  the  sockets  involved  In  a  two-way  conversation 
over  the  network  appears  below. 


* 


USER  (HOST)  COMPUTER 


USER  OUTPUT 
SOCKET 


I 


USER  INPUT 
SOCKET 


DATACOMPUTER 


Figure  4-1.  Network  connections  to  the  datacomputer 


A  host  computer  is  identified  on  the  network  either  by 
a  number  or  by  an  alphabetic  name,  1  ike  BBN-TENEX.  A  socket 
within  a  given  host  is  Identified  by  a  number;  send  sockets 
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have  odd  numbers  and  receive  sockets  even  ones.  For  a 
connection  to  be  opened,  both  hosts  Involved  must  request 
that  It  be  opened.  Likewise,  after  data  transmission  Is 
complete,  both  hosts  must  close  their  ends  of  the 
connection.  The  period  of  time  during  which  network 
connections  are  open  between  a  user  host  and  the 
datacomputer  Is  called  a  session. 

In  the  user  program's  dialogue  with  the  datacomputer, 
the  transmission  In  one  direction  consists  largely  of 
datalanguage  requests,  while  messages  from  the  datacomputer 
are  sent  In  the  other  direction,  to  the  user  program.  The 
sockets  at  the  datacomputer  that  are  used  for  these  purposes 
are  cal  led  the  datalanguage  I nout  socket  and  the 
datalanguage  output  socket.  The  terms  datalanguage 
input/output  port  are  also  used.  These  ports,  like  the 
PORTs  that  a  user  can  create  with  datalanguage  CREATE 
requests,  are  channels  for  the  input  and  output  of 
information.  However,  the  purpose  of  the  datalanguage  ports 
Is  to  receive  datalanguage  and  transmit  datacomputer 
messages;  the  purpose  of  a  user  PORT  is  to  transmit  or 
receive  data. 

The  protocol  by  which  a  user  program  can  set  up 
datalanguage  Input  and  output  sockets  connected  to  its  own 
output  and  Input  sockets  Is  described  In  Appendix  D  of  this 
document . 


SttH£hr.onUa.t.I.Qn 

Since  use  of  the  datacomputer  typically  Involves  the 
Interaction  of  two  programs  at  opposite  ends  of  a 
communication  network  with  a  finite  time  delay,  steps  must 
be  taken  to  ensure  that  the  programs  remain  In  synchrony 
with  each  other.  If  they  do  not,  the  user  program  might 
blithely  go  on  sending  datalanguage  when  the  datacomputer 
expects  data  or  might  receive  diagnostic  messages  when  It 
expects  a  list  of  directory  node  names. 

To  avoid  such  problems,  the  datacomputer  generates  a 
variety  of  messages  that  keep  the  user  program  Informed  of 
what  Is  going  on.  The  messages  fall  Into  several 
categories:  there  are  error  messages,  which  will  be 
discussed  In  a  later  section;  Informational  messages,  which 
can  safely  be  Ignored  or  merely  logged  by  a  user  program; 
and  synchronization  messages,  some  of  which  at  least  must  be 
processed  by  the  user  program  to  ensure  proper 
communication.  The  first  character  of  the  message  differs 
from  category  to  category,  allowing  the  user  program  easily 
to  differentiate  the  various  classes  of  message. 
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Prefix  Type  of  Message 


?,  -,  or  ♦  error  message 

;  informational  message 

.  synchronization  message 

Other  special  characters  may  be  added  as  datacomputer 
message-prefix  characters  in  future  versions.  The  letters, 
digits,  tab,  and  space  will  never  be  used  as  message 
prefixes,  however. 


The  datacompu ter ' s  messages  all  follow  a  common  format, 
which  includes  the  special  header  character  just  described, 
a  letter  and  three  digits  that  a  program  can  use  to  identify 
the  message,  the  date  and  time  of  the  message's 
transmission,  and  a  variable-length  string  of  text  that  can 
be  read  by  a  human  user.  Specifically,  the  format  is: 

. X999  dd-mm-yy  hhmm:ss  (TAB)  TEXT  STRING  (CR,  LF) 

where  .  represents  the  header  character,  X999  represents 
the  message  identifier  (for  example,  1210),  dd-mm-yy 
represents  the  day,  month,  and  year  (for  example,  25-09-73), 
hhmm:ss  represents  the  time  on  a  24-hour  clock  in  hours, 
minutes,  and  seconds,  (TAB)  represents  a  tab  character,  and 
(CR,  LF)  represents  the  carriage  return,  line  feed 
characters  that  terminate  the  message.  All  alphabetic 
characters  in  the  message  are  capitalized.  Note  that  the 
message  may  be  very  long  (too  long  to  print  on  a  72-column 
printer,  for  instance),  so  a  user  program  that  processes 
datacomputer  messages  may  have  to  format  them  to  be 
readabl e . 

In  this  manual,  only  the  invariant  parts  of  messages 
will  be  displayed;  that  Is,  the  header  character,  the 
identifying  letter  and  digits,  and  the  message  text. 


To  illustrate  the  use  of  synchronization  messages  in 
pacing  interaction  with  the  datacomputer,  consider  these 
two: 

.1210  LAGC:  READING  NEW  DL  BUFFER 
. J900  FCFINI:  END  OF  SESSION 

The  first  message,  .1210,  is  sent  by  the  datacomputer  over 
the  datalanguage  output  socket,  and  hopefully  received  by 
the  user  program  over  an  input  socket,  whenever  the 
datacomputer  is  ready  to  accept  datalanguage  requests.  The 
user  program  will  in  general  respond  to  this  message  by 
transmitting  a  JJufi  of  datalanguage.  A  line  is  some  number 
of  characters  (currently  there  Is  an  upper  limit  of  about 
2500)  terminated  by  either  the  character  sequence  carriage 
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return,  line  feed  (ASCII  codes  15,  12  octal)  or  the  single 
character  eol  (37  octal).  On  a  line  may  be  one  datalanguage 
request  (terminated  by  a  semicolon),  several  requests  (each 
terminated  by  a  semicolon),  or  a  portion  of  a  request. 

In  the  first  two  cases,  when  the  datacomputer  receives 
the  requests  (and  if  they  contain  no  errors)  It  will  proceed 
to  execute  them,  (typically  generating  messages  and/or 
initiating  data  transfers  as  It  does).  Following  execution, 
it  will  again  send  the  .1210  message  signifying  that  it  is 
again  ready  to  receive  datalanguage.  In  the  third  case,  the 
datacomputer  will  continue  to  send  .1210  messages,  prompting 
the  user  program  for  lines  of  datalanguage,  until  a  complete 
request  has  baen  assembled;  the  request  will  then  be 
executed  as  described  above. 

The  second  message,  .J900,  is  sent  by  the  datacomputer 
at  the  end  of  a  session.  The  user  program  may  request  that 
the  session  end  by  sending  the  datacomputer  a  control-Z 
(ASCII  code  32  octal)  in  response  to  a  .1210  message.  The 
datacomputer  responds  to  control-Z  by  executing  an  end  of 
session  procedure,  which  involves  closing  any  open 
containers,  deleting  TEMP  PORTs,  and  sending  the  .J900 
message.  The  user  program  may  then  close  its  network 
connections  with  the  datacomputer. 

Synchronization  after  an  error  is  discussed  in  the 
section  entitled  Error  Messages  below. 


IcaasmLttLnft  Data  through  the  p.ala Language  P.orts 

Often,  a  user  program  will  need  to  send  data  over  the 
network  to  be  stored  at  the  datacomputer,  or  to  process  data 
that  it  receives  from  the  datacomputer.  If  all  of  the  data 
is  described  as  ASCII,  then  this  may  be  done  by  using  the 
datalanguage  input  or  output  port. 

To  reference  data  that  he  or  she  will  transmit  through 
the  datalanguage  input  socket,  the  user  need  only  open  a 
PORT  and  use  it  on  the  right-hand  side  of  an  assignment  in 
datalanguage.  When  the  assignment  is  executed,  data  will  be 
accepted  through  the  datalanguage  input  port  and  assigned  to 
whatever  container  appears  on  the  left  side  of  the  request. 

Similarly,  to  output  data  through  the  datalanguage 
output  socket  so  that  it  can  be  picked  up  by  the  user 
program,  all  that  Is  needed  in  datalanguage  is  a  PORT  used 
on  the  left-hand  side  of  an  assignment.  Any  data  assigned 
to  that  container  will  be  transmitted  out  through  the 
datalanguage  output  port  over  the  network. 
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Of  course/  performing  this  feat  requires  the  use  of 
more  synchronization  messages.  To  treat  the  data-lnput  case 
f 1 rst: 


.1231  OCPBO:  (DEFAULT)  INPUT  PORT  OPENED 
.1251  OCPBC :  (DEFAULT)  INPUT  PORT  CLOSED 

After  the  user  program  has  sent  the  datalanguage  assignment 
request  that  references  the  open  input  PORT#  the 
datacomputer  will  transmit  the  .1231  message  over  the 
datalanguage  output  port.  The  message  signals  that  input 
data  is  now  expected  through  the  datalanguage  input  port/ 
and  the  user  program  should  send  the  data.  Data 
transmission  is  terminated  by  a  control-Z  character#  which 
causes  the  datacomputer  to  send  the  .1251  message  confirming 
that  data  transmission  is  finished.  The  next 
synchronization  message  will  be  .1210#  a  request  for  more 
datalanguage. 

The  synchronization  procedure  governing  data  output 
through  the  datalanguage  output  port  Is  similar.  The 
messages  are 

.1241  OCSOP:  (DEFAULT)  OUTPUT  PORT  OPENED 
.1261  OCSCL:  (DEFAULT)  OUTPUT  PORT  CLOSED 

When  the  assignment  statement  Is  executed  which  requests 
that  data  be  output  through  the  datalanguage  port#  the 
datacomputer  first  sends  .1241#  followed  by  the  requested 
data,  followed  In  turn  by  .1261.  The  datacomputer  does  not 
output  a  control-Z  at  the  end  of  the  data.  The  user  program 
can  use  these  messages  to  separate  out  the  data  from  all 
other  Information. 


Open i ng  Secondary  Pnr  t 

Instead  of  a  datalanguage  port#  an  additional  network 
connection  .or  secondary  port  can  be  used  for  transmitting 
data.  Non-ASCII  data#  including  an  ASCII  STR  with  a 
preceding  count  or  a  non-ASCII  delimiter#  must  be 
transmitted  over  a  secondary  port.  The  CONNECT  request  sets 
up  the  secondary  port. 

The  CONNECT  request  names  an  open  PORT#  and  gives  a 
host  (that  is#  a  computer  on  the  network)  and  socket  number 
to  which  that  PORT  is  to  refer.  As  mentioned  above#  if  a 
CONNECT  request  is  never  executed  for  a  PORT#  It  will  refer 
to  the  socket  from  which  the  user  program  transmits 
datalanguage  (if  It  is  a  READ  PORT)  or  the  socket  at  which 
the  user  program  receives  the  datacomputer ' s  messages  (a 
WRITE  or  APPEND  PORT),  The  form  of  the  CONNECT  request  Is 
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CONNECT  <pathname>  TO  <address>  ; 

where  <pathname>  is  the  node  name#  comlete  name  (i.e. 
starting  with  %top)  or  simple  login  name  (i.e.  starting 
immediately  subordinate  to  the  login  node)  of  an  open  PORT# 
and  <address>  can  have  several  forms.  It  can  be  one  of 

<socket-no>  the  decimal  number  of  a  socket  at  the 
user's  host  computer. 

<hjst-no>  <socket-no>  where  <host-no>  Is  the  decimal 
number  of  a  computer  on  the  ARPA  network 

' <host-name> '  <socket-no>  where  <host*name>  is  the  host 
computer's  TENEX  alphabetic  name 

<host-name>  <socket-no>  where  <host-name>  is  the  host 
computer's  TENEX  alphabetic  name 
(such  as  'CCA') 

OR  '<local-f i le-designator>'  This  last  form  of  <address> 

does  not  refer  to  the  network#  but  is 
included  here  for  completeness. 

<local-fi 1  e-designator >  is  a  TENEX 
file  designator  that  refers  to  a  file 
at  the  datacomputer  site. 


A  CONNECT  may  be  executed  any  time  the  PORT  is  open# 
but  it  does  not  actually  establish  the  network  connection. 
Those  connections  are  established#  used#  and  then  closed 
again  during  the  execution  of  an  assignment  statement  in 
datal anguage#  and  CONNECT  merely  sets  up  the  socket  address 
to  be  used  when  the  PORT  is  later  referenced  in  an 
assignment. 

A  DISCONNECT  request  may  b:>  used  to  cause  a  CONNECTed 
PORT  to  refer  once  again  to  the  datal anguage  input  or  output 
port. 


DISCONNECT  <pathname>  ; 


Two  CONNECT  requests  may  be  issued  for  the  same  PORT  without 
an  intervening  DISCONNECT. 


Additional  synchronization  messages  are  generated  at 
the  time  a  CONNECTed  PORT  is  used  in  an  assignment 
statement.  These  messages  are 


.1230  OCPBO: 
;  I  239  OCPBO: 
.1250  OCPBC : 
.1240  0CP00: 


OPENING  INPUT  PORT 
INPUT  PORT  OPENED 
CLOSING  INPUT  SOCKET 
OPENING  OUTPUT  PORT 
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; 1 249  0CP00:  OUTPUT  PORT  OPENED 
.1260  OCPOC:  CLOSING  OUTPUT  SOCKET 

When  a  CONNECTed  PORT  Is  used  on  the  right-hand  side  of  an 
assignment  (that  *s,  In  READ  mode),  the  .1230  message  Is 
sent  over  the  datalanguage  output  port.  This  signals  the 
user  program  that  the  datacomputer  Is  attempting  to  open  a 
network  connection  to  the  host  and  socket  specified  by  the 
CONNECT  request  for  the  PORT.  The  user  program  should  thus 
open  Its  end  of  the  connection  Itself  (If  It  is  a  connection 
to  a  different  socket  on  the  user  program’s  own  host)  or 
ensure  that  the  third  host  opens  Its  end  of  the  connection 
at  this  time  (If  It  Is  a  connection  to  another  host  on  the 
network) . 

The  ;  1  2 39  message  Indicates  that  Indeed  the  network 
connection  was  opened  correctly.  After  this  message  is 
received,  data  ran  be  transmitted,  terminated  by  closing  the 
network  connection.  Once  the  connection  Is  closed,  the 
datacomputer  sends  .1250  over  the  datalanguage  output  port, 
signaling  the  user  program  that  use  of  the  secondary  network 
connection  is  complete.  The  .1250  may  precede  or  follow  the 
closing  of  the  connection  on  the  user's  side. 

The  messages  for  output  PORTs  work  similarly,  with 
.1240  signaling  that  the  output  network  connection  is  being 
opened,  ; 1 249  that  the  connection  is  opened,  and  .1260  that 
output  is  complete  and  the  connection  is  being  closed. 

If  there  are  errors  in  the  data,  other  messages  will  be 
sent  before  the  .1250  or  .1260  message.  This  would  be  the 
case,  for  example.  If  the  data  does  not  match  the 
descr ipt ion. 

A  user  program  can  Interrupt  the  datacomputer ' s 
transmission  of  data;  see  Appendix  D  for  details. 

The  form  CONNECT  <pathname>  TO  < local -f I le-des ignator>; 
may  be  useful  to  those  with  large  amounts  of  data  to  send  to 
the  datacomputer.  In  some  cases,  the  shipment  of  magnetic 
tapes  by  air-freight  produces  higher  bit  rates  than  sending 
the  data  over  the  network;  the  magnetic  tape  may  then  be 
addressed  from  datalanguage  as  a  local  file.  Contact  CCA 
for  Information  on  this  procedure. 


Srrar.  Messages 

Datacomputer  error  messages  will  In  general  be  seen  by 
a  human  user,  although  they  have  header  characters  which 
make  them  potentially  processable  by  a  smart  user  program. 
Error  messages  fall  into  several  categories,  distinguished 
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by  their  first  character. 

First  Cha  ^  ;ter  Meaning 


indicates  a  datacomputer  or 
system  bug.  A  user  program 
should  rarely  see  one  of  these. 


Examples: 

?U000  TRDN:  NODE  CHAIN  SNAFU 
?U0Q0  DKWR :  DISK  I/O  WRITE  ERROR 


indicates  a  user  error  -- 
typically  bad  datal anguage,  data/ 
or  l/o  handling.  A  debugged  user 
program  should  rarely  see  one  of 
these. 

Examples: 

-U000  LPNM :  FORARG  NOT  DIRECT  LIST  MEMBER 

-1246  OCSOP:  CAN'T  OPEN  OUTPUT  PORT  (BAD  CONNECT  ARCS?) 


♦  indicates  a  circumstantial  error, 

such  as  a  file's  being  busy,  or 
an  error  which  Is  due  to  current 
datacomputer  limitations. 

Examples:  +U000  0CD0P:  CAN'T  OPEN  FILE  (SOMEBODY  ELSE  UPDATING 

♦L000  DM  I N:  DESCRIPTOR  TOO  LARGE 


After  the  datacomputer  generates  one  or  morr  error 
message.  It  follows  a  special  procedure  to  resynchronize 
itself  with  the  user.  This  procedure  Involves  waiting  for  a 
special  character,  control-L  or  form  feed  (ASCII  14  octal), 
to  be  transmitted  by  the  user.  That  is,  after  the  error 
message  the  datacomputer  sends 

.1220  LAEB :  LOOKING  FOR  CONTROL-L 

This  is  repeated  for  each  line  of  input  it  receives  on  the 
datalanguage  Input  port  until  the  user  sends  a  control-L 
character.  Following  receipt  of  a  control-L,  .1210  will 
again  be  sent  and  datalanguage  requests  again  processed. 

More  severe  action  must  be  taken  following  certain 
system  or  ?-type  errors.  One  of  the  following 
synchronization  messages  may  be  generated: 
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. J151  FCERRH:  RESTARTING  THE  REQUEST  HANDIER 
. J140  FCREIN:  REINITIALIZING  USER  JOB 
. J910  FCERRH:  CRASHING  JOB 

The  .J151  message  Indicates  that  TEMP  PORTS  have  been 
deleted;  otherwise#  the  status  of  the  session  remains  the 
same  (PORTs  and  FILES  will  still  be  open#  etc.).  This 
message  will  usually  be  followed  by  .1220#  a  request  for 
control -L. 

The  .J140  message  Is  more  serious.  The  user's  job  Is 
„omr1ete1y  reinitialized#  leaving  his  status  the  same  as 
when  the  session  was  begun.  this  message  will  also  be 
fol lowed  by  .  I  220. 

The  .J910  message  Indicates  a  condition  so  severe  that 
the  datacomputer  does  not  know  how  to  recover.  The  user's 
job  Is  crashed  and  the  datalanguage  network  connections 
closed.  That  Is#  the  session  Is  forcibly  ended. 

If  this  happens#  and  also  If  the  user's  network 
connections  to  the  datacomputer  are  accidentally  broken#  the 
datacomputer  will  do  Its  best  to  close  his  open  PORTs  and 
FILEs  in  an  orderly  manner.  However#  If  the  user  was  In  the 
process  of  transmitting  data  Into  a  FILE#  the  last  few 
thousand  characters  of  data  his  program  sent  may  have  been 
lost  In  transit  and  not  Incorporated  Into  the  FILE. 

Not  much  In  general  can  be  said  about  handling  ?  or 
errors#  except  that  a  human  user  will  have  to  read  and 
Interpret  the  text  of  the  error  message  In  each  case#  and 
(in  the  case  of  -  errors)  correct  the  datalanguage  he  is 
having  his  program  send. 

+  errors#  on  the  other  hand#  could  be  processed  by  a 
user  program.  The  most  reasonable  thing  to  do  In  many  cases 
Is  to  wait  five  minutes  and  retry  the  datalanguage  request 
that  caused  the  error.  For  example#  a  FILE  which  was  busy 
(i.e.  In  use  by  someone  else)  may  be  free  by  that  time#  so 
the  second  rttempt  to  use  It  may  be  successful. 

Messages  beginning  with  +L  are  an  exception  to  this#  In 
that  the  appropriate  time  to  wait  may  be  several  weeks 
Instead  of  minutes.  Such  messages  Indicate  limitations  of 
the  current  datacomputer  system#  such  as  limitations  Imposed 
by  Internal  table  sizes.  A  new  version  of  the  datacomputer 
may  remove  many  of  these  limitations.  Realistically#  this 
means  that  +L  messages  are  like  -  messages  In  that  a  program 
probably  could  not  handle  them. 
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Appendix  A:  Summary  of  Datalanguage  Syntax 


The  following  is  the  complete  BNF  (Backus  Normal  Form) 
specification  of  datalanguage  syntax  for  version  0/10  of  the 
datacomputer. 


Requests 


<reouest>  ; 


Directory  Requests 


<request> 

<request> 

<request> 

<request> 

<  request> 
<request> 
<request> 
<request> 
<request> 

<  request> 
<request> 


*  LOGIN  < log  in  body>  ; 

*  CREATE  <create  body>  ; 

=  DELETE  <de1 ete  bcdy>  ; 

*  OPEN  <open  body>  ; 

*  CLOSE  <close  body>  ; 

*  CONNECT  <connect  body>  ; 

*  DISCONNECT  disconnect  body>  ; 

*  MODE  <mode  body>  ; 

■  CREATEP  <createp  body>  ; 
a  DELETEP  <deletep  body>  ; 

*  LIST  <11 st  body>  ; 


Data  Transfer  Requests 


<  request> 

<  request> 


<direct  assignment  ; 
<for  loop>  i 
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Di rectory 


Pathnames 


<pathname> 

<pathname> 

<pathname> 

<pathname> 

<pathname> 


<complete  pathname> 

<simple  complete  pathname> 
<1ogln  pathname> 

<simple  login  pathname> 
<open  node  name> 


<noae  name>  <ident!fler> 

<node  name>  <ldentifier>  (  <password  string>  ) 

<password  string)  <string  constant) 

<simp1e  node  name)  <identifier) 


<complete  pathname)  STOP  .  <node  name) 

<complete  pathname) 

<complete  pathname)  .  <node  name) 


<simple  complete  pathname) 

STOP  .  <simple  node  name) 

<simple  complete  pathname) 

<simple  complete  pathname)  .  <slmple  node  name) 


< log  in  pathname)  ::=  <node  name) 

<login  pathname)  <logln  pathname)  .  <node  name) 


<simple  login  pathname)  < simple  node  name) 

<simple  login  pathname) 

<simple  login  pathname)  .  <simple  node  name) 


<.open  node  name)  <simple  node  name) 


<node  pathname)  <complete  pathname) 

<node  pathname)  <logln  pathname) 


<open  pathname) 
<open  pathname) 
<open  pathname) 


<simple  complete  pathname) 
<simple  login  pathname) 
<open  node  name) 
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D 1  rectory 


Requests 

< log  In  body>  STOP 

<log!n  body>  <node  pathname> 

<create  body>  <slmp1e  node  n?'*e> 

<create  body>  : : * 

<node  pathname>  .  <s!mple  node  name> 

<create  body>  <data  description) 

<create  body)  : : « 

<node  pathname)  .  <data  description) 

<de1ete  body)  : :  *  ** 

<delete  body)  <1ogtn  pathname) 

<delete  body)  =  < login  pathname)  .  ** 

<open  body)  <node  pathname) 

<open  body)  <node  pathname)  <mode> 

<close  body)  IfcOPEN 

<close  body)  ::=  <open  pathname) 

<connect  body)  : : * 

<open  pathname)  <tenex  file  specification) 
<connect  body)  : : = 

<open  pathname)  <network  specification) 

<tenex  file  specification)  <strlng  constant) 

<network  specification)  <socket  number) 

<network  specification) 

<host  specification)  <socket  number) 

<socket  number)  ::•*  <  Integer  constant) 

Chost  specification)  ;:*=  <integer  constant) 

<host  specification)  : :  *  identifier) 

<host  specification)  <string  constant) 

<dIsconnect  body)  <open  pathname) 

<mode  body)  ::=  <open  pathname)  <mode) 

<mode>  : : *  READ 
<mode>  : : *  WRITE 
<mode>  APPEND 

<mode>  : WRITE  DEFER 
<mode)  APPEND  DEFER 
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<createp  body>  <node  pathname> 

<createp  body>  : : ■ 

<node  pathname)  <prlvllege  tuple  specification) 
<prlvi1ege  tuple  specification) 

<prlvllege  tuple  option) 

<prlvl1ege  tuple  specification) 

<prlv!1ege  tuple  specification) 

<prlv!1ege  tuple  option) 

<prlvl1ege  tuple  option)  ,  U  »  <user  Identity) 

<privi1ege  tuple  option)  ,  H  *  <host  Identity) 

<prlvllege  tuple  option)  ,  S  ■  <socket  Identity) 

<prlv!1ege  tuple  option)  t  P  *  <password  string) 

<prlvllege  tuple  option) 

,  G  ■  <grant  privilege  list) 

<privilege  tuple  option) 

/  D  ■  <deny  privilege  list) 

<prlv!1ege  tuple  option) 

,  N  ■  <privl1ege  tuple  Index) 

<user  Identity)  : : ■  ** 

<user  Identity)  <user  node) 

<user  Identity)  ::=  <user  node  set) 

<user  identity)  <user  node)  .  ** 

<user  identity)  <user  node  set)  .  ** 

<user  Identity) 

<user  node)  .  <user  node  set)  .  ** 

<user  node)  <ldentlfler> 

<user  node)  <user  node)  .  <identlfler> 

<user  node  set)  : : ■  * 

<user  node  set)  <user  node  set)  .  * 

Chost  identity)  ANY 

<host  identity)  LOCAL 

<host  Identity)  < Integer  constant) 

<socket  Identity)  ANY 

<socket  Identity)  <lnteger  constant) 

<grant  privilege  list)  ::*=  <grant  privilege) 

<grant  privilege  list) 

<grant  privilege  listXgrant  privilege) 

<grant  privilege,  : : *  C 
<grant  privilege)  L 

<grant  privilege)  R 

<grant  privilege)  W 

<grant  privilege)  A 

<deny  privilege  list)  <deny  privilege) 

<deny  privilege  list) 

<der.y  privilege  llstXdeny  privilege) 

<deny  privilege)  ::=  R 
<deny  privilege)  W 

<deny  privilege)  A 

<privilege  tuple  index)  <integer  constant) 

<deletep  body)  : : ■ 

<node  pathname)  <prlvllege  tuple  Index) 
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<1  i  st  body>  : : 
< 1 1 st  body>  : : 
<1 1 st  node  set> 
< 1 1 s t  node  set> 
<1 1 st  node  set> 
< 1 1 s t  node  set> 
< 1 i st  node  set> 
< 1 1 s t  node  set> 
< 1 i s t  node  set> 
< 1 1 st  node  set> 
<  1 !  s t  option> 

< 1 i st  opt ion> 

<1 1st  option> 

< 1 1 st  optlon> 

< 1 i st  opt ion> 

<1 ist  optfon> 

< 1 1 st  option) 

<1 Ist  option) 


< 1 i st  node  set) 

< 1 i s t  node  set)  < 1 1 s t 
STOP 
%0PEN 

•  J  s  * 

•  •  *  ** 

<open  node  name) 

: : ■  <node  pathname) 
<node  pathname)  . 
<node  pathname)  . 

-  3;  NAME 

-  ^DESCRIPTION 

*  *0ESC 

«  ^SOURCE 
«  ^ALLOCATION 

*  %ALL0C 

-  ^PRIVILEGE 
=  %PRIV 


option) 


* 

** 
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Data  Description 


<datatype>  <compound  datatype) 

<datatype>  <simple  datatype) 

<datatype)  <string> 

<compound  datatype)  LIST 

<compound  datatype)  <structure) 

<structure>  STRUCTURE 

<structure>  STRUCT 


<s?mple  datatype)  BYTE 

<simoie  datatype)  <integer) 

<integer>  =  INTEGER 
< integer)  I  NT 


<stri ng> 
<strl  ng> 
<stri  ng 
<str ing 
<stri ng 
<stri ng 
<stri ng 
<str i ng 
<stri ng 


: : *  <str i ng  type) 
<string  type) 
type)  STRING 

type)  STR 

interpretation) 
interpretation) 
i nterpretat i on)  : :  ■ 
interpretation) 
interpretation)  ::a 


<string  interpretation) 


ASCII 
ASCI  I  8 
BYTE 
I  NT 

INTEGER 
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<data  description) 

<simp1e  node  name)  <functton) 

<outermost  description) 

<function>  FILE 

< function)  PORT 

<function>  TEMPORARY  PORT 

<function>  TEMP  PORT 

<outermost  description)  ::«*  LIST  <descript ion) 

<outermost  description) 

LIST  <compound  datatype  options)  <descr i pt ion) 
<outermost  description)  <string) 

<outermost  description)  <string)  <string  options) 

<outermost  description)  <descr I pt i on) 

description)  : : * 

LIST  dimension)  descri  pt  ion) 
descr  i  pt  i on)  s :  * 

LIST  dimension)  dompound  datatype  options) 
descri  ptlon) 
descr  i  ption)  = 

<structure)  <descri pti ons)  END 
description)  s :  = 

^structure)  <compound  datatype  options) 
descriptions)  END 
description)  BYTE 

descri  ption)  BYTE  dimple  datatype  options) 

description)  <integer) 

<description>  :i=  <integer)  <simple  datatype  options) 

description)  ::=  dtring)  dimension) 
description) 

dtring)  dimension)  dtring  options) 
descriptions)  descri  pt  Ion) 

descriptions)  descr  i  pt  Ions)  descri  ption) 
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description  option>  s:« 
<description  option) 
<descrlptlon  option) 
<description  option) 
inversion  option) 

<inversion  option) 

<byte  size  option) 

<f  I  Her  option)  : :  ■  ,  F 

<f  i  Her  option)  : :  ■  ,  F 

<variab!e  length  option) 
<variable  length  option) 
<varfab1e  lengtii  option) 
<variable  length  option) 
<variabie  len/,th  option) 
<variable  length  option) 

/  D  ■  'donquote  character) 


<lnverslon  option) 

<byte  size  option) 

<f I l ler  option) 

<variab1e  length  option) 
i  ■  f) 

I  ■  I 

B  ■  <lnteger  constant) 

■  < integer  constant) 

■  '<nonquote  character)' 

,  C  -  1 
,  P  ■  EOF 
,  P  -  FOB 
,  P  -  F.OR 

,  D  *  < Integer  constant) 


<compound  datatype  options) 

Ccompound  datatype  option) 

<compound  datatype  options) 

<compound  datatype  options) 

<compound  datatype  option) 

<compound  datatype  option)  <byte  size  option) 

<compound  datatype  option)  <f 1 1 1 er  option) 

<compound  datatype  option) 

<variable  length  option) 


dimple  datatype  options) 
dimple  datatype  option) 
dimple  datatype  options) 
dimple  datatype  options) 

dimple  datatype  option) 

dimple  datatype  option)  inversion  option) 

dimple  datatype  option)  <byte  size  option) 

dimple  datatype  option)  < f i  1  ler  option) 


dtri  ng 
<strl  ng 
dtr  I  ng 
dtr  I  ng 
dtr  i  ng 
dtr  i  ng 


options) 

options) 

option) 

option) 

option) 

option) 


dtring  option) 

dtring  options)  dtring  option) 
inversion  option) 

<byte  size  option) 

<f i 1 ler  option) 

<variable  length  option) 


dimension)  (  <integer  constant)  ) 

dimension)  (  ,  <integer  constant)  ) 

dimension)  : :  = 

(  <integer  constant)  ,  <integer  constant)  ) 
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Data  Transfer 


<data  reference)  <ldentifler> 

<data  reference)  ss*  <data  reference)  .  <!dentlfier) 
<constant>  ss*  <string  constant) 

<constant)  ss*  <integer  constant) 

<assignment)  ss*  <data  reference)  *  <data  reference) 
Assignment)  ss*  <data  reference)  *  <constant) 

<dlrect  assignment)  ss*  Assignment) 

{direct  assignment)  {Implicit  for  loop) 

<implicit  for  loop)  ss*  {assignment)  {qualifier) 

{for  loop)  Si*  FOR  {input)  {for  body)  END 
{for  loop)  ::*  FOR  {input)  {qualifier)  {for  body)  END 
{for  loop)  ::*  FOR  {output)  ,  {Input)  {for  body)  END 
{for  loop)  ss* 

FOR  {output)  ,  {input)  {qualifier)  {for  body)  END 
{input)  ::*  {data  reference) 

{output)  ::*  {data  reference) 

{for  body)  {for  loop) 

{for  body)  ::*  {for  loop)  ; 

{for  body)  ::*  {assignment  list) 

{for  body)  s:«  {assignment  list)  ; 

{assignment  list)  ::*  {assignment) 

{assignment  list)  ss* 

{assignment  list)  ;  {assignment) 

{qualifier)  ss*  WITH  {boolean  expression) 


{boolean  expression) 

{boolean  expression) 

{boolean  expression) 

{boolean  expression) 

{boolean  expression) 

{boolean  expression)  AND 
{boolean  expression)  ss* 

{boolean  expression)  OR  {boolean 


{relational  expression) 

(  {boolean  expression)  ) 
NOT  {boolean  expression) 
ANY  {boolean  expression) 


{boolean  expression) 
expression) 


{relational 
{data  re 

{relational 
{data  re 
{compar i son 
{compar i son 
{compar i son 
{compar i son 
{compar i son 
{compar i son 


expression)  ss* 
ference)  {comparison 
{data  reference) 
expression)  ss* 
ference)  {comparison 
operator)  ss*  EQ 
operator)  ss*  NE 
operator)  ss*  GT 
operator)  ss*  GE 
operator)  ss*  LT 
operator)  ss*  LE 


operator) 


operator)  {constant) 
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Lexical  I  terns 


<1exica1  item)  identifier) 

<iexica1  I  tern)  integer  constant) 

<iexica1  item)  <strlng  constant) 

iexicai  item)  <autonomous  character) 

<identifier>  ietter) 

<ldentifier>  % 

identifier)  <ident*fler)  ietter) 

<identifier>  <identifier)  t 

<identifier)  identifier)  <digit) 

<lnteger  constant)  <digtt) 

<Integer  constant)  =  <integer  constant)  <diglt> 

<string  constant)  '<string  constant  body)' 

<string  constant  body)  Cnonquote  character) 

<string  constant  body) 

<string  constant  body)  <nonquote  character) 
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Character  Set 


<nonqucte  character>  <letter> 

<nonquote  character>  % 

<nonquote  character>  <dlglt) 

<nonquote  character>  <autonomous  character) 

<nonquote  character)  (space) 

<nonquote  character)  (horizontal  tab  --  HT) 

<nonquote  character) 

<nonquote  character)  "" 

<separator>  (space) 

<separator>  (horizontal  tab  --  HT) 

Separator)  <eol> 

<eol>  (end  of  line  --  octal  37) 

<eol>  <carriage  return)  <llne  feed) 

<carriage  return)  (carriage  return  --  CR) 

<line  feed)  j:«  (line  feed  --  LF) 
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< autonomous 
<autonomous 
< autonomous 
<autonomous 
< autonomous 
<autonomous 
< autonomous 
<autonomous 
< autonomous 
< autonomous 
Autonomous 
<autonomous 
<autonomous 
< autonomous 
<autonomous 
< autonomous 
<autonomous 
<autonomous 
< autonomous 
< autonomous 
<autonomous 
<autonomous 
<autonomous 
< autonomous 
<autonomous 
< autonomous 
<autonomous 
<au tonomous 
<autonomous 


character> 

character> 

character> 

character> 

character> 

character> 

character> 

character> 

character) 

character) 

character) 

character) 

character) 

character) 

character) 

character) 

character) 

character) 

character) 

character) 

character) 

character) 

character) 

character) 

character) 

character) 

character) 

character) 

character) 


t 


! 

# 

$ 

& 

( 

) 

* 

♦ 


/ 


«  < 
s  m 

«  > 

■  7 

•  0 
.  "B 

*  "/ 
-  "E 
.  »| 


"6 
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Notes 


Character  codes  are  7  bit  ASCII. 

Separators  are  always  permitted  between  lexical  Items, 
except  between  grant  privileges,  between  deny 
privileges,  and  inside  string  constants. 

Comments  may  be  inserted  wherever  separators  are 
allowed.  Comments  begin  with  */**  and  end  with  **/* 
(e.g.,  /*  THIS  IS  A  COMMENT  */). 

<carriage  return>  and  <ilne  feed>  may  only  appear 
together  In  that  order  (as  an  <eoi>).  Otherwise  they 
are  treated  as  control  characters,  which  are  rejected. 


Appendix  B:  Reserved  Words 


AND 

ANY 

ASCII 

ASCI  18 

BYTE 

CLOSE 

CONNECT 

CREATE 

CREATEP 

DELETE 

DELETEP 

DISCONNECT 

END 

EQ 

FI  LE 
FOR 
GE 
GT 
I  NT 

INTEGER 

LE 

LIST 

LOGIN 

LT 

MODE 

NE 

NOT 

OPEN 

OR 

PORT 

STR 

STRING 

STRUCT 

STRUCTURE 

WITH 

SOPEN 

STOP 
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Appendix  C:  Inversions  Technical  Considerations 


An  inversion  is  a  secondary  data  structure  that 
the  datacomputer  can  use  to  improve  its  efficiency  in 
retrieving  data  by  content  from  a  datalanguage  FILE. 
Specifically/  an  entry  in  the  inversion  is  constructed 
for  every  STR  with  the  l/iversion  attribute.  For  each 
data  value  which  occurs  for  the  STR/  the  inversion 
contains  pointers  to  all  the  records  in  the  FILE  for 
which  that  STR  contains  that  value. 

For  example#  if 

CREATE  PEOPLE  FILE  LIST 
PERSON  STRUCT 

NAME  STR  (15) 

SOCSECNO  STR(9)/I-D 

SEX  STR  (1)  /*  'M'  OR  ' F ' *// I -D 

ZIP  STR( 5) / I *D 

END; 

then  the  data  structure  for  the  inversion  on  SEX 

contains  pointers  to  all  Instances  of  PERSONS  with  SEX 
equal  to  'F'/  and  similarly  for  'M' ,  Thus,  evaluation 
of  a  simple  FOR  Input-spec  like 

FOR  ...  /  PEOPLE. PERSON  WITH  SEX  EQ  'M' 

would  be  quick  and  simple/  and  would  require  only  a 

read  of  the  inversion/  not  any  reading  of  the  FILE 

PEOPLE  itself. 

An  inversion  is  not  only  constructed  automatically 
by  the  datacomputer  when  the  FILE  is  loaded  with  data# 
but  is  automatically  maintained  (updated)  whenever 
information  in  the  FILE  is  updated. 


Unfortunately/  even  if  an  inversion  for  the 
appropriate  STR  exists/  the  datacomputer  cannot  always 
use  it  for  the  evaluation  of  input-specs/  and  must 
sometimes  resort  to  time-consuming  searches  of  the 
FILE.  In  particular,  the  inversion  can  be  used  only 
when  the  STR  is  compared  with  a  constant  us i ng  the 
operators  EQ  and  NE.  That  i s. 
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PEOPLE. PERSON  WITH  ZIP  EQ  '02138'  OR  ZIP  EQ 

'02139' 

OR  ZIP  EQ  '02140'  OR  ZIP  EQ 

'02141' 


can  be  evaluated  directly  from  the  inversion. 


However/ 


PEOPLE. PERSON  WITH  ZIP  GE  '02138' 
AND  ZIP  LE  '02141' 


while  it  still  can  be  evaluated/  cannot  take  advantage 
of  the  inversion  and  so  would  be  much  less  efficient 
datalanguage. 


Furthermore/  when  the  STR  is  a  member  of  an  inner 
LIST/  only  the  oehrator  EQ  can  be  evaluated  using  the 
inversion.  A  sequential  search  is  used  for  evaluating 
NE. 


Complex  Boolean 
several  comparisons/ 
with  all  comparisons 
those  containing  no 
inversion/  and  those 
comparisons.  The  first 
the  datacomputer  will  use 


expressions#  those  involving 
fall  into  three  classes'  those 
evaluable  from  the  inversion# 
comparisons  evaluable  from  the 
which  mix  the  two  kinds  of 
two  classes  pose  no  problem; 
the  Inversion  to  evaluate 


expressions 

expressions 


in  the  first  category# 
in  the  second  category. 


and  not  for 


For  mixed  expressions#  the  datacomputer  will  use 
the  inversion  as  much  as  it  can.  For  the  present#  this 
can  be  stated  as  follows:  if  the  Boolean  expression  is 
of  the  form 


<expr>  AND  <expr>  AND  ... 

(where  <expr>  is  an  arbitrary  Boolean  expression#  in 
parentheses  if  it  contains  OR)  then  the  datacomputer 
will  separate  the  <expr>s  Into  those  that  can  be 
completely  evaluated  from  the  Inversion  anc  tho.e  that 
cannot#  and  will  process  those  that  can  use  the 
inversion  first.  The  <expr>s  that  cannot  use  the 
inversion  are  evaluated  by  an  exhaustive  search  of  the 
set  of  records  selected  by  the  earlier  <expr>s. 

For  an  example#  take  the  above  FILE#  PEOPLE. 
Suppose  a  list  of  all  males  with  ZIP  GT  '02000'  were 
desired.  ZIP  is  indeed  inverted#  but  since  the 
operator  GT  is  Involved#  the  evaluation  of  that  part  of 
the  Boolean  expression  cannot  use  the  inversion.  As  a 
result#  in 
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FOR  ...  #  PEOPLE. PERSON  WITH  Zl P  GT  '02000' 

AND  SEX  EQ  'M' 

the  datacomputer  will  first  use  the  Inversion  to  find 
the  set  of  all  PERSONS  with  SEX  EQ  'M'#  and  only  this 
smaller  set  of  PERSONS  would  be  searched  for  the 
desl red  Zl Ps . 

A  more  difficult  example:  consider  the  problem  of 
retrieving  all  the  records  for  events  that  occurred 
between  10:05  on  the  25th  and  15:07  of  the  30th  from  a 
FILE  that  Is  Inverted  on  DAY  but  not  on  TIME.  A 
straightforward  way  to  do  this  Is 

...  WITH  ( DAY  EQ  '25'  AND  TIME  GT  '10:05') 

OR  (DAY  EQ  '26')  OR  (DAY  EQ  '27')  OR 

•  •  • 

OR  (DAY  EQ  '30'  AND  TIME  LT  '15:07') 

but  this  Is  quite  inefficient:  the  Inversion  cannot  be 
used  at  all#  for  this  Boolean  expression  Is  mixed  and 
Is  not  set  up  as  a  series  of  terms  connected  by  AND. 
The  best  way  to  express  this  condition  Is 

...  WITH  (DAY  EQ  '25'  OR  DAY  EQ  '26'  OR  ...  OR 
DAY  EQ  '30') 

AND  (DAY  NE  '25'  OR  TIME  GT  '10:05') 

AND  (DAY  NE  '30'  OR  TIME  LT  '15:07') 

In  this  case#  only  records  for  the  correct  six  days  are 
retrieved  by  the  first  term#  so  only  they  need  to  be 
searched  through  for  the  evaluation  of  the  second  and 
third  terms. 


Future  versions  of  the  datacomputer  will 
automatically  optimize  mixed  Boolean  expressions# 
freeing  the  user  from  this  task. 


The  computation 
I nvers Ion 
operational 
any  user 
I  nversl on. 


of  the  space  requirements  for  an 
Is  best  left  to  the  datacomputer ' s 
staff  at  CCA#  who  should  be  contacted  by 
Interested  in  setting  up  a  data  file  with  an 
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Appendix  D:  Network  Interaction  with  the  Datacomputer 


The  procedure  for  establishing  network  connections 
..ith  the  datacomputer  is  that  documented  in  J.  Postel/ 
Official  Telnet  j:  Logger  Initial  Connection  Protocol, 
NIC  7103/  15  dune  1971.  The  following  is  a  simplified/ 
informal  description  of  that  procedure. 

The  datacomputer  listens  for  connections  on  a 
well-advertised  socket/  currently  number  103  (octal)  at 
CCA/  host  number  37  (octal).  This  is  an  odd-numbered 
or  send  socket.  The  user  program  wishing  to  use  the 
datacomputer  will  address  this  socket  from  a  socket  on 
his  own  host  computer  --  say  from  socket  number  U.  U 
must/  of  course/  be  an  even  number  or  a  receive  socket. 
The  user  program  should  read  one  32-bit  byte  of 
information  over  this  connection  and  then  immediately 
close  it  (leaving  socket  CCA-103  free  for  other  users). 
This  byte  of  information  is  a  socket  number  at  the 
datacomputer  —  say  socket  D.  D  will  be  an  even 
number . 

The  last  step  is  the  opening  of  two  network 
connections/  the  permanent  datalanguage  connections. 
They  are 


from  D+l  at  CCA  to  U+2  at  the  user  host 
and  from  U  +  3  at  the  user  host  to  P  at  CCA. 

Note  that  U+2  is  even  (since  U  is)  and  D+l  is  odd 
this  is  the  datalanguage  output  socket.  Also/  U+3  is 
odd/  and  0  is  even:  the  datalanguage  input  socket. 
These  connections  will  remain  in  effect  until  the  end 
of  the  datalanguage  session. 


The  byte  size  of  the  permanent  datalanguage 
connections  is  8  bits.  The  datacomputer  sends/  and 
expects  to  receive/  7-bit  ASCII  characters 
right-justified  in  8-bit  bytes. 


Two  special  network  control  signals/  INS  and  INR/ 
may  be  used  to  interrupt  the  datacomputer.  INS/  for 
Jjlterrupt  the  gender/  may  be  sent  at  any  time  during 
the  processing  of  a  request  and  stops  data  output  from 
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the  current  request.  No  error  message  or  other 
acknowledgement  will  be  generated;  the  output  simply 
stops,  i NS  might  be  useful  to  a  program  which  receives 
output  fr'  the  datacomputer  and  displays  i t  to  a  human 
operator  sitting  at  a  teletype;  at  the  request  of  the 
user,  the  program  could  send  INS  to  stop  an  overly-long 
pri ntout. 

I  NR/  for  .interrupt  the  receiver/  performs  all  the 
functions  of  INS.  In  addition/  compilation  or  any 
other  processing  that  is  under  way  when  INR  is  received 
will  be  aborted/  possibly  generating  an  error  message 
and  a  request  for  control-L.  INR  thus  requests  a  more 
immediate  halt  than  does  INS. 


Appendix  E:  Implementation  Restrictions 


A  number  of  datalanguage  restrictions  specific  to 
Version  0/10  are  collected  here  for  ready  reference. 
Note  that  some  of  these  restrictions  have  been 
mentioned  In  the  body  of  this  manual,  while  others  have 
not. 


1.  There  Is  a  restriction  on  the  containers 
that  can  be  referenced  in  the  body  of  a  FOR- loop. 
Consider  the  following  example: 

CREATE  FF  FI LE  LIST 
PERSON  STRUCT 

NAME  STR  (15) 

ADDRESS  STR  (20) 

CITY  STR  (10) 

STATE  STR  (2) 

ZIP  STR  (5) 

SOCSECNO  STR  (10) 

DEPENDENTS  LIST  (10) 

NAME  STR  (15) 

END; 

CREATE  PP  PORT  LIST 
PERSON  STRUCT 

NAME  STR  (15) 

SOCSECNO  STR  (15) 

END; 

To  output  all  the  DEPENDENTS .NAMEs  from  the  file  FF, 
together  wi th  the  SOCSECNO  of  the  PERSON  whose 
DEPENDENTS  they  were, 

FOR  PP. PERSON, FF. PERSON 
NAME-NAME; 

SOCSECNO -SOCSECNO; 

END; 

This  example  as  written  will  work  In  datalanguage  0/10. 
However,  If  SOCSECNO  occurred  after  DEPENDENTS  In  the 
description  of  FF. PERSON,  the  request  would  fail  due  to 
a  compiler  restriction. 

When  an  Inner  FOR-loop  is  processing  a  LIST  which 
occurs  within  a  STRUCT,  references  may  he  made  In  the 
body  of  that  FOR  to  objects  which  occur  before  that 
LIST  in  the  STRUCT,  but  not  after  the  LIST. 
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There  are  certain  cases  of  assignment  involving 
inner  LISTs  which  the  compiler  in  Version  0/10  cannot 
handle.  For  example#  given  two  structures  of  the 
following  format: 

LI  FILE  LIST 
SI  STRUCT 

A1  STR  (8) 

A2  LIST  (4) 

B2  STR  (6) 

END; 

and 

L2  PORT  LlS'i 
SI  STRUCT 

A1  STR  (8) 

A2  LIST  (4) 

B2  STR  (6) 

END; 

the  following  FOR-loop  will  not  work: 

FOR  LI. SI#  L2.S2 

FOR  A2 . B2# A2 . & 2 
S1«S1 

END 

END; 

The  A2  lists  are  In  use  by  the  inner  FOR-loop  (FOR 
A2.B2,A2.B2)  when  the  assignment  S1*S1  is  encountered. 
The  datacomputer  expands  S1»S1  Internally  Into: 

Al-Al 

FOR  L1.S1.A2.B2#L2.S1.A2.B2 
B2*B2 

END; 

This  constitutes  a  second  use  of  the  A2  lists#  which 
cannot  be  handled. 

2.  In  Version  0/10  of  datal anguage#  there  Is  one 
general  restriction  on  sequences  of  nested  FOR-loops# 
which  can  be  stated  as  follows: 


Sequences  of  nested  FOR-loops  are  restricted  to  be 
a  number  (possibly  0)  of  FOR-loops  without  output 
LISTs#  followed  by  an  arbitrary  number#  at  least  1#  of 
FOR-loops  with  output  LISTs. 


For  example# 

FOR  A 
FOR  B  #  C 
(ASSIGNMENT) 

(ASSIGNMENT) 

END; 

END; 


FOR  A  FOR  A 

FOR  B 

FOR  C#D  END; 

(ASSIGNMENT) 

END; 

END; 


END; 

The  first  two  examples  are  legal#  whereas  the  third 


not . 


i  s 
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3.  A  FOR-loop  with  no  output  LIST  can  contain 
only  one  datalanguage  statement  as  the  F0R-body#  not  a 
series  of  statements.  Because  of  restriction  2 ,  that 
one  statement  must  be  a  FOR. 

This  does  not  apply  to  a  FOR  with  an  output  LIST. 

4.  The  only  comparison  operators  which  can  be 
evaluated  from  an  Inversion  are  EQ  and  NE.  All  other 
comparison  operators  must  be  evaluated  by  a  linear 
search  through  a  set  of  records.  If  the  container 
being  compared  Is  a  member  of  an  Inner  list#  only  the 
EQ  comparison  operator  can  be  evaluated  from  an 
Inversion. 

5.  It  Is  Impossible  to  assign  members  of  a  LIST 
without  setting  up  a  FOR-loop  (either  explicitly  or 
Implicitly).  For  example/  given  the  PORT  Is: 

CREATE  LI  PORT  LIST  (5) 

SI  STR  (3); 

The  following  assignment  Is  Illegal: 

L1.S1='F00'; 

because  It  treats  the  five  members  of  SI  as  If  they 
were  a  single  data  Item. 

6.  Two  outermost  containers  with  the  same  name 
may  not  be  open  at  the  same  time.  This  Is  true  even 
though  the  containers  may  have  different  pathnames  In 
the  directory. 

7.  1 f  an  output  PORT  Is  punctuated/  all 

assignments  before  each  punctuation  character  must  be 
completed  before  any  assignments  are  made  after  the 
punctuation  character.  That  is#  the  datacomputer 

cannot  back  up  over  punctuation  In  an  output  PORT.  For 
example/  given  an  output  PORT  of  the  form: 

PP  PORT  LIST 
SI  STRUCT 

A1  STR  <3)/P«E0R 

A2  STR  (3)/P«E0R 

ENO 

assignments  must  be  made  In  the  same  order  as  the  STRs 
appear  in  the  STRUCT. 

Al-'FOO'; 

A2»: BAR' ; 

will  take  effect  correctly/  but 

A2* ' BAR ' ; 

Al*  *  F  00 ' ; 
wi  1 1  not. 

Because  of  the  Internal  paging  of  the 
datacomputer/  STRUCTs  containing  long  STRs  (l.e. 
greater  than  2560  ASCII  characters)  have  a  similar 
restriction,  for  example/  the  LIST 
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FF  FILE  LIST 
SI  STRUCT 

A1  STR  (10000) 

A2  STR  (10000) 

A3  STR  (10000) 

END 

may  have  assignments  done  only  in  the  same  order  as 
they  appear  in  the  STRUCT. 
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Appendix  F:  Differences  between  0/9  and  0/10 


The  following  Is  a  list  of  changes  which#  when 
perfc  ied  on  0/9  datalanguage#  results  In  the 
datalanguage  for  0/10.  The  changes  are  purely  user 
specifiable  (!.*.  syntactic)  features. 


Add! ttons 


Login 

The  LOGIN  request 
The  login  context 
The  %T0P  context 

Prl vl leges 

The  CREATEP  request 
The  DELETEP  request 
Passwords  In  pathnames 

Simple  pathnames  (without  passwords)  for  open  nodes 
Variable  length 

Data  description  options  P,  P#  C 
Dimension  --  (mln#max) 

The  datatype  BYTE 

The  Implicit  FOR  loop 

The  boolean  operator  ANY 

Defer  mode  --  WRITE  DEFER#  APPEND  DEFER 


New  data  description  options  —  1*1#  B#  F 
New  LIST  options  --  ^ALLOCATION#  ^PRIVILEGE 
LIST  STOP 


LIST  * 
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CLOSE  I0PEN 

String  interpretations  --  ASCI  I ,  ASCI  I  8,  BYTE 
Synonyms  —  STRUCTURE,  STRING 


Modi f i cations 


**  replaces  %ALL 

Elimination  of  the  .  between  LIST'S  nodes  and  option 
fcNAME  is  now  an  explicit  LIST  option 
DELETE  <pathname>.**  is  now  explicit 
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D 


10.  ADMINISTERED  BY  COOEj  S2202A 

Mr.  J.  McDonough 
Defense  Contract  Administration 
Services  Region,  Boston 
666  Summer  Street 
I  Boston,  Massachusetts  02210 


13.  SHIPPED  TO  CODE |  y7DQ 

Defense  Advanced  Research 
Architect  Building 
l*i00  Wilson  Boulevard 
Attn:  Dr.  Craig  Fields 
Arlington,  Virginia  22209 


rojects  Agy. 


12. PAYMENT  WILL  BE  MADE  BY  CODE!  S2202A 

Disbursing  Officer 
Defense  Contract  Administration 
Services  Region,  Boston 
666  Summer  Street 
Boston,  Massachusetts  02210 


14. MARKED  for  code 


Same  as  13. 


S'  ITEM 

NO. 

16.  STOCK/PART  NO.  OESCRIPTION 

(Indicate  number  of  shipping  containers  -  type  of 
contomcr  •  contoiner  number. ) 

]7'  OUANTITY 
SHlP/REC’D  » 

18. 

UNIT 

17. 

UNIT  PRICE 

20. 

AMOUNT 

0002 


Semi-Annual  Technical  Report 


21.  ppocupcment  ouality  assurance 

jZZ  jZZ  A.  ORIGIN  ZZ  jZZ  B.  (DESTINATION  ~~ 

I  I  ?QA  1  1ACC  EPT  ANCE  of  lifted  items  ho*  been  mo-te  1  1  PQA  1  1  ACCEPTANCE  of  listed  item*  hot  been  mode 

by  rvj  or  under  my  supervision  ond  they  conform  to  contract,  by  mo  or  under  my  supervision  ond  they  conform  to  controct, 
except  os  notod  herein  or  on  supporting  documents.  except  os  notod  heroin  or  on  supporting  documents. 


22.  RECEIVER'S  USE 

Ojontitios  shown  in  column  17  wore  received  in 
opporent  good  condi  except  os  noted. 


DATE  I.VCLIVED 


SIGNATURE  OF  AUTH  GOV  f  Hwr 


SIGNATURE  OF  AtJTH  GOVT  REP 


TYPEO  NAME 
ANO  OFFICE 


23. CONTRACTOR  USE  ONLY 


SIGNATURE  OF  AUTH  GOVT  REP 


TYPEO  NAME 
ANO  TITLE 


TYPEO  NAME 
ANO  OFFICE 

•  If  qusnhty  received  by  the  Government  is  iFj  some  o» 
quooti/y  shipped,  mdicofc  by  (  rf  fmjrk,  if  dif¬ 
ferent,  enter  ocfuol  quantity  received  below  quantity 
shipped  ond  encircle. 


